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!
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
