bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Dreimann <>
Subject Re: [BEP-0003] Misc questions
Date Wed, 12 Dec 2012 17:21:32 GMT
On 12 Dec 2012, at 16:31, Gary Martin <> wrote:

> On 12/12/12 15:18, Jure Zitnik wrote:
>> Hi,
>> 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.
> Ah yes, I forgot about my ideas for that. For the purposes of unique keys I was thinking
of including some kind of prefix as part of the name - not necessarily the product namespace
as we could consider it better to leave this as a constant with a means to link the prefix
to the namespace.
> The problem with just adding fields to each model is not so much a problem from the point
of view of 3rd party plugins accessing those models that are modified in such a way, but rather
with those resource tables that are added by the third party plugins. These would have to
be modified to add the product to their tables too. Is the suggestion that we do that modification
for externally defined resources or only provide the ability for specific plugins?
>>>> 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.
> I keep playing with the idea of whether the null product could be the default. The only
problem I see with that after a small amount of consideration is making sure it is possible
to access it from within other products. It is probably just as well to create a product called
'main' or 'default' or similar to simplify things.
> However, I don't think that is strictly what the section in BEP-0003 is talking about.
It seems to be more of a question of whether there is anything different about deployment
scripts for bh multiproduct enabled installations and, perhaps, whether we provide admin commands
to help add specific products as deployable entities. I think that Peter is right to suggest
that there doesn't seem to be a strict reason to do this when it might encourage extra work
for adding more products.
> I could be misinterpreting everyone of course!

I believe the installation should always be 'multi product enabled'. It's the safer option
(i.e. not causing problems later if additional products are required) and multi product is
one of the core features of Bloodhound. If a user is really adverse to the possibility of
adding additional products he can enforce this via permissions or just install plain Trac.

From a UI perspective the initial product could be considered as a 'null' product until a
name is given by the user, but all that is really a separate discussion as far as I can tell.

>>>> 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.
>> +1
>>> 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.
>> +1
>> Cheers,
>> Jure

View raw message