On 2/22/13 4:48 PM, Olemis Lang wrote:
On 2/22/13, Jure Zitnik <[email protected]> wrote:
[....]
How I see things will evolve is the following - we won't be changing
IEnvironmentSetupParticipant interface. I should be kept untouched to
keep the backward compatibility with existing plugins. As discussed in
one of the previous threads, the interface will still be used as before
but on per product basis.
Environment setup process should be completely apart of product scope
. It's a TRAC_ADMIN tasks i.e. nothing to do with anything you'd like
to do in product scope . Besides it blocks system execution (i.e.
upgrade msg, DB schema modifications, revert on error , etc, etc, etc
...) and we should not be doing such things ... or otherwise stated
TRAC_ADMIN should be doing that once and products will only be able to
use what is available in global environment , no more ...
First, I agree that the environment (global, that is) setup should be
apart from product scope.
It's a bit of a different story on product 'setup'. Now, we agreed that
the non multi-product aware components should have a separate view of
the database. In addition to system resource tables (components,
versions, tickets and such), this view also comprises of custom tables
that the component might introduce. These tables are introduced (and
later upgraded for that matter) from within IEnvironmentSetupParticipant.
So, if we want to have a separate set of component tables per product
(this is what 'separate view of the database' implies), we should use
IEnvironmentSetupParticipant interface and run it within the specific
product scope. And this would normally happen when adding product. So
from the non multi-product aware component perspective, adding a product
would seem much like creating a new environment.
Multi-product aware components on the other hand would be handled
differently as I described in my mail yesterday...
Cheers,
Jure
