I noticed that GraphDB, in contrast to RDF4J, does not allow dots in repository IDs. We have versioned repositories containing some taxonomies. The version number is used in repository ID, so for example: taxonomy-0.1.3.
While this works fine in RDF4J, I have to call such a repository differently in GraphDB, e.g. taxonomy-0_1_3. I'd like to be able to use the same set of queries with federation (SERVICE calls referencing the taxonomy repositories) on both RDF4J and GraphDB, so that I could switch between the two based on the use case. In RDF4J, I could work around version numbers by having a federated store with version-less ID pointing to a specific versioned repository. But, as far as I know, GraphDB does not support federated repositories.
Does anyone have an idea how to overcome such a problem? Or are there any plans for supporting less restrictive repository IDs in GraphDB?
Thanks a lot
GraphDB supports SPARQL Federation (or do you mean something else by "federated repositories"?)
I'll post your request as an enhancement task (GDB-5023), but without business context it'll have low priority...
Related
Using free, self-managed GitLab
Due to group-level custom project templates available only to paid tiers (even there there are restrictions) I am looking into an alternative solution using a simple project, where
in the code repository each branch provides a template
in the wiki each code repository branch has an entry documenting what the template does
I know that the wiki and the code are actually two separate repositories.
In its nature a template is a construct that offers a pre-made setup for working on a reoccurring task. A group template adds the additional restriction that the reoccurring task applies to more then one individual.
In order to limit tomfoolery and people pushing whatever they want thinking it's worth becoming a group-level template (even though they made something real quick to tackle a problem that has been long forgotten and even they themselves will not work on it ever again) I would like to impose access restrictions to all members. Beside the maintainer/owner all other members are assigned a developer role. All branches are protected so a change of an existing branch or the creation of a new one can only be done through a merge request leading to an assessment whether the committed changes to the repository are actually worthy of becoming a template for the whole group.
Many members of my group have the bad habit of choosing poor names for functionality they have developed (e.g. a script called jennifers_help_script_23.py) and not documenting what was actually implemented. And yes, we are not a software development company but a research institute. :D So in order to improve the documentation and the ability to actually reuse some of the quite useful things that people have developed I would like to make it mandatory for people to provide documentation if they want their stuff to be added to the project.
So the question here is can a user submit a code merge request that also acts as a merge request for a change in the wiki (e.g. user has created a new template, which requires also a new wiki page documenting that template) or the two have to be handled separately given the nature of a GitLab project (wiki separate from code)?
I was thinking maybe each branch (representing a template) will contain a markdown file that will be inserted as a wiki automatically after the merge request has been approved. However I don't know how to automate this. I am currently looking into uploading a file to the wiki using the GitLab API, hoping a can somehow add a trigger in GitLab to execute the "command" upon a successful merge. Needless to say I am quite new to all of this.
Reading odoo API or source code your would encounter the term ir ( usually as a prefix ), I can't seem to figure out what does it stand for ?
for example
ir_sequence
The meaning is Information Repository.
Although there's no official statement on the matter AFAIK, I tend to think about it as Internal Resource (various resources the system needs to work fine, but not actually meaningful for normal users day-to-day work), just as I think about the res prefix as Resource (which is not internal, it's for normal usage).
As example, res.config is to create visual configuration wizards to be presented to a user that may not be the sysadmin (he could be just the sales responsible for example), but many settings are actually stored as ir.config_parameter records, which are only accessible for the sysadmin and are used extensively by Odoo internal code.
Earlier nuget package 'Microsoft.Bot.Builder.Azure' had AzureTableStorage, AzureBlobStorage and CosmosDbStorage but now the latest version has only AzureBlobStorage and CosmosDbStorage .
What if I need to used the TableStorage also the IStorage of Microsoft.Bot.Builder.IStorage doesn't allow table storage but only blob and cosmos dB storage.
Is table storage not supported for IStorage or am I missing something?
I have also tried upgrading all nuget packages and used target framework .NET Core 2.2
The provider for table storage was removed before the SDK was released due to limitations that the team didn't have time to work around. That said, as you can see, there is an IStorage abstraction that would allow you to write your own implementation on top of Azure Table Storage if that's something you think you need.
Honestly, I don't know if I see much of a point in it. If you don't need the ability to perform ad-hoc queries over the data then blob storage is the cheapest, fastest option. If you do want to perform ad-hoc queries over the data, then table storage was never going to help you anyway due to it only having partition/row key indexability, so you'd need to go to something more powerful like CosmosDB which can index on all of the data.
FWIW, if you wanted to resurrect the AzureTableStorage implementation, you can always grab the last version that existed before it was removed from the SDK here.
I have an existing NServiceBus 2.6 application that I want to start moving to 3.0. I'm looking for the minimum change upgrade in the first instance. Is this as simple as replace the 2.6 DLLs with the 3.0 Nuget packages or are there other considerations?
For the most part the application migration is quite straight forward, but depending on your configuration and environment, you may need to make the following changes:
The new convention over configuration for endpoints may mean you will need to rename your endpoints to match your queue names (#andreasohlund has a good post about this).
persistence of saga, timeouts, subscriptions etc. now defaults to RavenDb, so if you use SQL Server to persist data, you need to make sure you have to correct profile and endpoint configuration. For SQL Server storage, make sure you add a reference to NServiceBus.NHibernate as it is no longer part of the core.
Error queues are now referenced differently using different configuration ie. use MessageForwardingInCaseOfFaultConfig instead of the regular MsmqTransportConfig error property. You should still be able to use it, but it will look for the MessageForwardingInCaseOfFaultConfig first.
Other than that, I don't think you need to do anything else to get you upgrade working. I modified some of my message definitions to take advantage of the new ICommand and IEvent interfaces as a way communicatinf intent more clearly.
Anyway, I'm sure there will be some cases that are specific to your environment that will require different changes but I hope this helps a bit.
I'm trying to configure a trac server we are using in my team, in order to avoid an undesired behaviour. We are mainly developing free and open-source software in the team, but we sometimes need to be able to build our early prototypes as completely private.
Because of our first constraint, we want our timeline to be visible for anonymous users. But because of the seconde constraints, we want some commits to be completely hidden from the external world, i.e. we don't want anybody else than us to be able to read the message and content of some commits in the timeline.
Unfortunately, I've been unable to configure Trac the proper way to reach this behaviour untli now. I wan't find a configuration that would let me manage the Timeline content with enough accuracy.
Consequently, I would like to know if such a configuration is possible with trac.
For information, I'm using Trac 0.12.2. The installed plugins are :
Trac 0.12.2
TracAccountManager 0.2.1dev-r7731
TracNav 4.1
The only permission I can see that is related to Timeline is TIMELINE_VIEW.
EDIT :
I have forgot to mention something. We don't want to loose the private commits. And we want them to display for registered users. Consequently, it's not a solution for us to remove them from the database.
EDIT 2 :
Ideally, we would like the commits' message to be displayed according to the right to read the content of our Subversion repository. The idea is that, if a commit is made on a part someone can't access, this person is not supposed to be able to read the message of the commit either.
EDIT 3 :
If we have a look in the configuration file of trac, we already can find :
permission_policies = AuthzSourcePolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy
and the authz_file variable is properly set too. Moreover, svn access to the private folders of the svn repositories can't be accessed by anonymous users.
You should set up authz checking for both your Subversion repository and your Trac installation. You can use the same permission file for both. For Subversion, see Path-based authorization in the SVN book. For Trac, enable and configure the trac.versioncontrol.svn_authz.AuthzSourcePolicy component.
This will allow you to have a very fine-grained control over who can access which part of the repository. Note that the implementation of AuthzSourcePolicy in Trac 0.12.2 has a few bugs that will be fixed in 0.12.3.
There are two ways of going about this :
1) You can directly edit the plugins that are running in trac, and add a module that helps you to filter these out at the code level (i.e. you can edit the behavior of the script to , say, only include commits which exclude certain key words). The timeline script is here (trac 2.4) : /usr/local/lib/python2.4/site-packages/trac/Timeline.py (here is an online diff snapshot of the source code : http://trac.edgewall.org/attachment/ticket/890/Timeline.py.diff)
2) You can remove the commits entirely - trac commits are derived from the sqlLite database (the schema is here http://trac.edgewall.org/wiki/TracDev/DatabaseSchema).
Of course, there also might be some fancy tools out there that provide a nice interface for editing the way the timeline looks.
Finally - temporarily, you can remove the timeline/roadmap entirely from the trac.ini file : http://www.gossamer-threads.com/lists/trac/users/28079
I confess that I've virtually no experience with the repository part of Trac, even less with using a repository with a variety of permissions across it's contents.
On the subject: Configuration is certainly not enough, see rblanks answer. While I've never seen the code for that functionality, I was wrong to suggest it doesn't exist. Because it is a central place and developed/supported in Trac core this is definitely the way to go.