bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <>
Subject Re: [BEP-0003] Misc questions
Date Wed, 12 Dec 2012 15:18:27 GMT

On 12/12/12 2:30 PM, Gary Martin wrote:
>> o Database schema changes
>> 1. Can we be exact with altered table list?

BEP-0003 updated with the list, currently SQLs targeted at enum, 
component, milestone, version and wiki tables are translated.

>> 2. Something that we might forgot: What about 3rd party plugin tables 
>> that
>> reference multiproductized Trac tables?
>>      Will probably need to proclaim these incompatible when more than 
>> one
>> product is in effect?
> Good point. To keep track of records from tables from third party 
> plugins, this approach doesn't quite work. I would have thought that 
> we would be better off using a separate table to keep track of the 
> resources that belong to a product. Is this another area that has not 
> been updated based on discussions?

The current SQL translator implementation would show 3rd party plugins a 
view of translated tables that would only include resources from the 
currently selected product scope. If the plugin makes a reference to a 
resource by it's name everything should work fine as the reference would 
be consistent each time when in that specific product environment (as 
the plugin would always get the same view of the database).

Things start breaking if there's a resource with the same name in 
multiple products, unless the translator is changed to return names with 
product namespace being prefixed to the actual resource name for 
example. The plugins would get version name 'BH:1.0' instead of '1.0' 
for example. Still, this doesn't solve the problem entirely as the 
plugin (that's not aware of products) would end up (in it's own tables) 
with references to different resources from different products and maybe 
that's not exactly what's expected to happen...

Keeping track of resource belonging to a product using a separate 
resource mapping table also unfortunately doesn't solve the issue. We'd 
need to change the schema anyway as in the current database model, all 
tables have 'name' column as their key. We could of course reference the 
same resource from different products using the separate mapping table 
but we'd be referencing the same record and changing the name of that 
record would change the resource in all products which is, at least imo, 
not what we want.

>> o Administration commands
>> This implies that we will have two different modes of operation (multi
>> product and single product) which will have to be chosen at
>> installation? Is this necessary? I can imagine users will start with 
>> single
>> product because it will be perceived simpler but will have additional 
>> work
>> to do when the need for second product arises.
> I struggle to see a reason to support a deploy-multiproduct admin 
> command at the moment, partly because I don't see a reason to go 
> beyond providing a basic product path based namespace resolution. More 
> on that below..

I think that we only have one mode of operation and that is multi 
product. Installation should initially setup a 'default' product and 
give the users the ability to add products as needed.

>> o Product resources namespaces
>> I remember there have been some debates on this a few weeks ago and it
>> seems this sections does not reflect them or any consensus if there 
>> was one.
> There may well not have been consensus so it is probably worth someone 
> attempting to review those discussions to see if there was much we 
> could agree on. However, I seem to remember that it ended with the 
> suggestion that webserver configuration should be able to sort out 
> most url schemes so we probably shouldn't worry about direct support.


> Using a path based approach should be good enough for now and I would 
> suggest dropping others for consideration as a later enhancement - 
> such a later enhancement could just be a bit of documentation of 
> course if that is considered enough.
>> o Per product repository
>> Maybe many-to-many? There are all sorts of things out there in the wild.
>> But probably not common enough to warren phase 1.
> Per product repositories does make good sense but it may be a good 
> simplification to avoid worrying about it too early. We should be able 
> to work with a set of globally defined repositories so we should make 
> sure that works first.


View raw message