You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Jure Zitnik <ju...@digiverse.si> on 2012/11/19 17:37:47 UTC
BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound] Proposals/BEP-0003
modified)
Hi all,
I updated the BEP-0003 with a (relatively short) draft proposal of
database schema changes required to support multi-product as a first
class citizen in Bloodhound, mostly to start the conversation on this topic.
The proposed change is based on my understanding of multiple 'product
environments' - that all persistent entities are stored within the same
database. If that is truly the case, all persistent per product
instances should somehow be linked to the product. My proposition (in
short) is:
* I suggest that the same approach is taken as with current
bloodhound_multiproduct plugin regarding tickets
* It should be up to the plugins to handle the entity's product relation
as needed/required
* Plugins should have the ability to query all entities regardless of
entity's product - there are number of cases when this will be required,
for example search plugin and ticket relations plugin
Cheers,
Jure
On 11/19/12 5:35 PM, Apache Bloodhound wrote:
> Page "Proposals/BEP-0003" was changed by jure
> Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=17>
> Revision 17
> Changes:
> -------8<------8<------8<------8<------8<------8<------8<------8<--------
> Index: Proposals/BEP-0003
> =========================================================================
> --- Proposals/BEP-0003 (version: 16)
> +++ Proposals/BEP-0003 (version: 17)
> @@ -94,6 +94,23 @@
>
> [=#product-env-idem] The following methods and options will behave exactly the same as the corresponding `parent_env`'s methods: ''get_system_info'' , ''components_section'' , '''TODO''' .
>
> +=== Database schema changes #database-schema-changes
> +
> +Products shall become a first-class citizen in ''Bloodhound''. To make this possible, some changes will be required at the database schema level, especially as multiple product environments are meant to be hosted in the same database instance.
> +
> +Currently, products are only supported in relation to tickets. Current implementation of `bloodhound_multiproduct` plugin extends the `ticket` table by adding custom field `product`. This field is used to reference products as defined in the `bloodhound_product` table.
> +
> +In addition to tickets, other entities should also be made ''product aware''. The product support should be, in a similar way to tickets, extended to (at least) the following database entities within ''Bloodhound'':
> +* versions
> +* milestones
> +* components
> +* priorities
> +* ...
> +
> +This could be accomplished using the same approach as used in relation to tickets - by extending the database tables with the 'product' field that would reference the product that the specified entities belong to.
> +
> +Another change required is the change of the fore mentioned table keys. As it currently stands, the key used in these tables is limited to the 'name' field. As this (in the modified schema) prevents users from creating versions/milestones/... with the same name for different products, key should be extended with the 'product' field.
> +
> == Rationale #rationale
>
> The following is a list of proposed features for multi product support in ''Bloodhound''. Goals related to compatibility are considered in [#backwards-compatibility Backwards compatibility] below. In each case you'll find notes explaining how candidate implementation will solve related issues.
> -------8<------8<------8<------8<------8<------8<------8<------8<--------
>
> --
> Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003>
> Apache Bloodhound <https://issues.apache.org/bloodhound/>
> The Apache Bloodhound (incubating) issue tracker
>
> This is an automated message. Someone added your email address to be
> notified of changes on 'Proposals/BEP-0003' page.
> If it was not you, please report to .
Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound]
Proposals/BEP-0003 modified)
Posted by Peter Koželj <pe...@digiverse.si>.
On 22 November 2012 18:08, Olemis Lang <ol...@gmail.com> wrote:
> On 11/22/12, Gary Martin <ga...@wandisco.com> wrote:
> > "Peter Koželj" <pe...@digiverse.si> wrote:
> >
> >>I was just wandering if we already have an idea of what "side-by-side"
> >>actually looks like.
>
> I thought I was clear enough on the subject . Side-by-side means Trac
> doing DB stuff their own way whereas we adopt a completely different
> DB schema ... but still making both solutions compatible above DB
> access layer ... and also that , in order to get to that point , we'll
> need to get to an agreement of some sort with Trac-dev .
>
Sorry if I missed or misunderstood something. I am still trying to figure
out wether we are thinking the same thing or not. Something definitely got
lost on the wire :(
By "whereas we adopt a completely different DB schema" are you thinking BH
and installed plugins do not use Trac tables at all as in create complete
new schema or a BH schema as a complementary solution? An example for let's
say "milestone" would clear things up.
Also I imagine that just fixing Trac with DAO/ORM is not enough, what about
all the plugins on Trac Hacks?
>
> >>As I pointed out that some aspects of the db model and multiproducts
> >>can
> >>not be fixed by adding tabels alone.
> >>
>
> It seems to me that you actually don't understand what I said .
> There's no disagreement on this particular subject . Why bother about
> discussing it further ? Since the very beginning I'm exploring the
> possibility of make Bloodhound DB schema diverge with respect to
> Trac's ... so we'd be using a different DB schema .
>
> ... BUT ... in order to make that work and still be able to merge
> changes from Trac trunk into vendor branch , etc ... in a way that we
> don't spend 80% of the time performing the merging process rather than
> developing Bloodhound , we still need to be in sync (... somehow ...)
> with them . That is a big deal because DB access code is scattered all
> over Trac source code and consists of a lot of SQL queries highly
> coupled to current Trac's DB schema . So what I'm trying to explore is
> the chance for making both projects converge towards a solution
> allowing to replace DB access code at once .
>
> ... at least I hope we won't entangle any more in discussing whether
> current DB schema is appropriate or not , please . I'm assuming that
> as a fact since the beginning .
> ;)
>
> >>After a discussion with Brane, one option (acceptable even by a purist
> >>like
> >>me:)) could be:
> >>
> >>Introduce product_prefix field in existing tables (version, milestone,
> >>wiki...) and make it part of primary key.
> >>
>
> yes , of course that would be the most evident way to go , but ...
>
> >>To maintain Trac and 3rd party plugin compatibility we could override
> >>Trac's db access mechanism (ProductEnvironment.db_*() or somewhere
> >>deeper)
> >>and parse incoming SQL to rebuild them with new model specifics by
> >>taking
> >>product prefix from url/ui session. Plugins that would actually need DB
> >>operations through multiple products would use some newer multiproduct
> >>db
> >>API.
> >>
>
> Even before Bloodhound existed I dedicated some time thinking of doing
> such a thing and always reached to the conclusion that this approach
> was worthless . But maybe somebody else has a winning card (i.e. idea)
> to succeed on this effort .
>
> >>Definitely worth investigating IMO
>
> of course ... though I won't follow too much if we go that way ,
> unless I notice something really interesting that makes me change my
> mind , of course . All this based on my pre-Bloodhound failed attempts
> to get things done that way.
>
Some input on that would be welcomed. We could focus on that problems first
to see if a fresh set of eyes can find a solution and avoid researching for
days only to come to the same conclusions.
>
> >> and no need for DAO if Trac rejects
> >>them.
> >>
>
> The DAO is just a well-known pattern I mentioned to make myself clear
> . Anything even similar allowing us to do the same thing would be fine
> too . I didn't mention ORM because
>
> 1. there are previous discussions at trac-dev
> on the subject and their answer has always been
> «no, why bother? we <3 SQL»
> 2. ORM APIs per-se reflect a lot of the underlying
> DB schema
>
> If Trac-dev reject the idea of course it's worthless to spend time
> thinking of it . That's not happened yet though .
>
> > I might be convinced to go with some kind of pre-parsing layer
> mechanism. It
> > could certainly get around some of the problems if plugins are not
> required
> > to know that they are anything other than a normal trac instance.
>
> IMO , the big deal is actually how to make all that work .
>
> > Plugins
> > that feel the need to be product aware could find out of course.
> >
>
> +1
>
> > It is worth noting that with the current form for non-ticket resource key
> > fields, it would be possible to just supply a milestone name (for
> example)
> > with an appropriate prefix.
>
> I was thinking of something similar too . The fact is that such
> approach doesn't scale to consider any kind of resource .
>
> > If you want them to stay constant then you could
> > just use a unique string and provide a translation in a table linking the
> > resource to the product. You could actually use the same approach with
> > tickets.
> >
>
> If this is somehow similar to TracRelations [1]_ proposal then I buy it !
> :)
>
> > I am not particularly convinced by the DAO idea at this point. I would
> > probably prefer an ORM
>
> Like I said I avoided to use the term ORM for historical reasons .
> ;)
>
> > but I don't see plugins supporting either idea for a
> > significant time without some major benefits to them.
> >
>
> That's mainly thinking in terms of core components . First things
> first , step by step
> ;)
>
> .. [1] TracRelations
> (http://trac.edgewall.org/wiki/TracDev/Proposals/TracRelations)
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound]
Proposals/BEP-0003 modified)
Posted by Olemis Lang <ol...@gmail.com>.
On 11/22/12, Gary Martin <ga...@wandisco.com> wrote:
> "Peter Koželj" <pe...@digiverse.si> wrote:
>
>>I was just wandering if we already have an idea of what "side-by-side"
>>actually looks like.
I thought I was clear enough on the subject . Side-by-side means Trac
doing DB stuff their own way whereas we adopt a completely different
DB schema ... but still making both solutions compatible above DB
access layer ... and also that , in order to get to that point , we'll
need to get to an agreement of some sort with Trac-dev .
>>As I pointed out that some aspects of the db model and multiproducts
>>can
>>not be fixed by adding tabels alone.
>>
It seems to me that you actually don't understand what I said .
There's no disagreement on this particular subject . Why bother about
discussing it further ? Since the very beginning I'm exploring the
possibility of make Bloodhound DB schema diverge with respect to
Trac's ... so we'd be using a different DB schema .
... BUT ... in order to make that work and still be able to merge
changes from Trac trunk into vendor branch , etc ... in a way that we
don't spend 80% of the time performing the merging process rather than
developing Bloodhound , we still need to be in sync (... somehow ...)
with them . That is a big deal because DB access code is scattered all
over Trac source code and consists of a lot of SQL queries highly
coupled to current Trac's DB schema . So what I'm trying to explore is
the chance for making both projects converge towards a solution
allowing to replace DB access code at once .
... at least I hope we won't entangle any more in discussing whether
current DB schema is appropriate or not , please . I'm assuming that
as a fact since the beginning .
;)
>>After a discussion with Brane, one option (acceptable even by a purist
>>like
>>me:)) could be:
>>
>>Introduce product_prefix field in existing tables (version, milestone,
>>wiki...) and make it part of primary key.
>>
yes , of course that would be the most evident way to go , but ...
>>To maintain Trac and 3rd party plugin compatibility we could override
>>Trac's db access mechanism (ProductEnvironment.db_*() or somewhere
>>deeper)
>>and parse incoming SQL to rebuild them with new model specifics by
>>taking
>>product prefix from url/ui session. Plugins that would actually need DB
>>operations through multiple products would use some newer multiproduct
>>db
>>API.
>>
Even before Bloodhound existed I dedicated some time thinking of doing
such a thing and always reached to the conclusion that this approach
was worthless . But maybe somebody else has a winning card (i.e. idea)
to succeed on this effort .
>>Definitely worth investigating IMO
of course ... though I won't follow too much if we go that way ,
unless I notice something really interesting that makes me change my
mind , of course . All this based on my pre-Bloodhound failed attempts
to get things done that way.
>> and no need for DAO if Trac rejects
>>them.
>>
The DAO is just a well-known pattern I mentioned to make myself clear
. Anything even similar allowing us to do the same thing would be fine
too . I didn't mention ORM because
1. there are previous discussions at trac-dev
on the subject and their answer has always been
«no, why bother? we <3 SQL»
2. ORM APIs per-se reflect a lot of the underlying
DB schema
If Trac-dev reject the idea of course it's worthless to spend time
thinking of it . That's not happened yet though .
> I might be convinced to go with some kind of pre-parsing layer mechanism. It
> could certainly get around some of the problems if plugins are not required
> to know that they are anything other than a normal trac instance.
IMO , the big deal is actually how to make all that work .
> Plugins
> that feel the need to be product aware could find out of course.
>
+1
> It is worth noting that with the current form for non-ticket resource key
> fields, it would be possible to just supply a milestone name (for example)
> with an appropriate prefix.
I was thinking of something similar too . The fact is that such
approach doesn't scale to consider any kind of resource .
> If you want them to stay constant then you could
> just use a unique string and provide a translation in a table linking the
> resource to the product. You could actually use the same approach with
> tickets.
>
If this is somehow similar to TracRelations [1]_ proposal then I buy it !
:)
> I am not particularly convinced by the DAO idea at this point. I would
> probably prefer an ORM
Like I said I avoided to use the term ORM for historical reasons .
;)
> but I don't see plugins supporting either idea for a
> significant time without some major benefits to them.
>
That's mainly thinking in terms of core components . First things
first , step by step
;)
.. [1] TracRelations
(http://trac.edgewall.org/wiki/TracDev/Proposals/TracRelations)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound] Proposals/BEP-0003 modified)
Posted by Gary Martin <ga...@wandisco.com>.
I might be convinced to go with some kind of pre-parsing layer mechanism. It could certainly get around some of the problems if plugins are not required to know that they are anything other than a normal trac instance. Plugins that feel the need to be product aware could find out of course.
It is worth noting that with the current form for non-ticket resource key fields, it would be possible to just supply a milestone name (for example) with an appropriate prefix. If you want them to stay constant then you could just use a unique string and provide a translation in a table linking the resource to the product. You could actually use the same approach with tickets.
I am not particularly convinced by the DAO idea at this point. I would probably prefer an ORM but I don't see plugins supporting either idea for a significant time without some major benefits to them.
Cheers,
Gary
"Peter Koželj" <pe...@digiverse.si> wrote:
>I was just wandering if we already have an idea of what "side-by-side"
>actually looks like.
>As I pointed out that some aspects of the db model and multiproducts
>can
>not be fixed by adding tabels alone.
>
>After a discussion with Brane, one option (acceptable even by a purist
>like
>me:)) could be:
>
>Introduce product_prefix field in existing tables (version, milestone,
>wiki...) and make it part of primary key.
>
>To maintain Trac and 3rd party plugin compatibility we could override
>Trac's db access mechanism (ProductEnvironment.db_*() or somewhere
>deeper)
>and parse incoming SQL to rebuild them with new model specifics by
>taking
>product prefix from url/ui session. Plugins that would actually need DB
>operations through multiple products would use some newer multiproduct
>db
>API.
>
>Definitely worth investigating IMO and no need for DAO if Trac rejects
>them.
>
>Peter
>
>On 22 November 2012 07:58, Olemis Lang <ol...@gmail.com> wrote:
>
>> On 11/22/12, Peter Koželj <pe...@digiverse.si> wrote:
>> > On 21 November 2012 18:08, Olemis Lang <ol...@gmail.com> wrote:
>> >
>> >> On 11/19/12, Jure Zitnik <ju...@digiverse.si> wrote:
>> >> > Hi all,
>> >> >
>> >> > I updated the BEP-0003 with a (relatively short) draft proposal
>of
>> >> > database schema changes required to support multi-product as a
>first
>> >> > class citizen in Bloodhound, mostly to start the conversation on
>this
>> >> > topic.
>> >> >
>> >> [...]
>> >>
>> >> Well , I'd suggest not to touch Trac tables for the moment ,
>specially
>> >> if we want to continue merging changes from Trac trunk into vendor
>> >> branch .
>> >>
>> >
>> > We already altered the "ticket" table with the multiproduct plugin.
>> > I would suggest that we multiproductize all entities in the same
>> consistent
>> > way whatever it is.
>> >
>>
>> Yes ? Now I notice .
>>
>> 1. What is that change for exactly ?
>> 2. Why do we need it if we use custom ticket
>> fields to link products and tickets ?
>>
>> ... please understand that you took the time to review the plugin in
>> detail while I've been busy with other tasks
>> ;)
>>
>> >
>> >>
>> >> IMO we should consider adding multi-product schema maybe working
>> >> side-by-side together with Trac's ... maybe not ... and refactor
>Trac
>> >>
>> >
>> > Can we elaborate on this side-by-side thing?
>>
>> Keeping our copy of Trac as similar as possible to Trac's , at least
>> keeping everything above db access layer compatible with it , while
>we
>> still use our own tables . That's what I meant . I was thinking about
>> encapsulating DB access using DAO or something similar ...
>>
>> In order to succeed in this effort we'll need to work together with
>> trac-dev for obvious reasons .
>>
>> > It might be our only option
>> > but it definitely sounds like horrible
>> > hack that will haunt BH to the end of it's days.
>> >
>>
>> ?
>>
>> > A challenge: How would we model/implement having two milestones in
>two
>> > different products with the same name? The same goes for versions,
>> > components, enum values and wikis.
>> >
>> > The interesting Trac db model is not making things easy for us.
>> >
>>
>> Sorry , but the starting point is to use DAO exactly for this very
>> same reason . That'd allow us to introduce our own multi-product DB
>> schema side-by-side with Trac's (i.e. Trac tables + BH tables ...)
>and
>> still make them both compatible at the data access level . That's
>what
>> DAO are for .
>>
>> So I hope you understand why I won't consider answering your question
>> since it looks like you didn't understand my intention .
>
>
>> >
>> >> code to use DAO in such a way we can override data access layer
>and
>> >> make it product-aware while all other business-specific layers on
>top
>> >> of it will still work .
>> >> I mentioned this in a separate thread but IMO that discussion
>should
>> >> take place in this thread .
>> >>
>> >> For the moment I've sent a request for comments [1]_ to trac-dev
>to
>> >> explore how much feasible migration to DAO will be . If there's
>> >> possitive feedback then it will be great news because we'll be
>able to
>> >> move forward with DB enhancements we need and still merge changes
>from
>> >> Trac trunk .
>> >>
>> >
>> > Here is to hoping but I think we should start thinking what will
>our
>> > strategy be if we do not like the answer.
>> >
>>
>> Yes , we can . However in any case moving forward with incompatible
>DB
>> changes for multi-product support will make merging from Trac trunk a
>> really painful experience . That's what my initial message was about
>> in first place .
>>
>> --
>> Regards,
>>
>> Olemis.
>>
>> Blog ES: http://simelo-es.blogspot.com/
>> Blog EN: http://simelo-en.blogspot.com/
>>
>> Featured article:
>>
Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound]
Proposals/BEP-0003 modified)
Posted by Peter Koželj <pe...@digiverse.si>.
I was just wandering if we already have an idea of what "side-by-side"
actually looks like.
As I pointed out that some aspects of the db model and multiproducts can
not be fixed by adding tabels alone.
After a discussion with Brane, one option (acceptable even by a purist like
me:)) could be:
Introduce product_prefix field in existing tables (version, milestone,
wiki...) and make it part of primary key.
To maintain Trac and 3rd party plugin compatibility we could override
Trac's db access mechanism (ProductEnvironment.db_*() or somewhere deeper)
and parse incoming SQL to rebuild them with new model specifics by taking
product prefix from url/ui session. Plugins that would actually need DB
operations through multiple products would use some newer multiproduct db
API.
Definitely worth investigating IMO and no need for DAO if Trac rejects them.
Peter
On 22 November 2012 07:58, Olemis Lang <ol...@gmail.com> wrote:
> On 11/22/12, Peter Koželj <pe...@digiverse.si> wrote:
> > On 21 November 2012 18:08, Olemis Lang <ol...@gmail.com> wrote:
> >
> >> On 11/19/12, Jure Zitnik <ju...@digiverse.si> wrote:
> >> > Hi all,
> >> >
> >> > I updated the BEP-0003 with a (relatively short) draft proposal of
> >> > database schema changes required to support multi-product as a first
> >> > class citizen in Bloodhound, mostly to start the conversation on this
> >> > topic.
> >> >
> >> [...]
> >>
> >> Well , I'd suggest not to touch Trac tables for the moment , specially
> >> if we want to continue merging changes from Trac trunk into vendor
> >> branch .
> >>
> >
> > We already altered the "ticket" table with the multiproduct plugin.
> > I would suggest that we multiproductize all entities in the same
> consistent
> > way whatever it is.
> >
>
> Yes ? Now I notice .
>
> 1. What is that change for exactly ?
> 2. Why do we need it if we use custom ticket
> fields to link products and tickets ?
>
> ... please understand that you took the time to review the plugin in
> detail while I've been busy with other tasks
> ;)
>
> >
> >>
> >> IMO we should consider adding multi-product schema maybe working
> >> side-by-side together with Trac's ... maybe not ... and refactor Trac
> >>
> >
> > Can we elaborate on this side-by-side thing?
>
> Keeping our copy of Trac as similar as possible to Trac's , at least
> keeping everything above db access layer compatible with it , while we
> still use our own tables . That's what I meant . I was thinking about
> encapsulating DB access using DAO or something similar ...
>
> In order to succeed in this effort we'll need to work together with
> trac-dev for obvious reasons .
>
> > It might be our only option
> > but it definitely sounds like horrible
> > hack that will haunt BH to the end of it's days.
> >
>
> ?
>
> > A challenge: How would we model/implement having two milestones in two
> > different products with the same name? The same goes for versions,
> > components, enum values and wikis.
> >
> > The interesting Trac db model is not making things easy for us.
> >
>
> Sorry , but the starting point is to use DAO exactly for this very
> same reason . That'd allow us to introduce our own multi-product DB
> schema side-by-side with Trac's (i.e. Trac tables + BH tables ...) and
> still make them both compatible at the data access level . That's what
> DAO are for .
>
> So I hope you understand why I won't consider answering your question
> since it looks like you didn't understand my intention .
> >
> >> code to use DAO in such a way we can override data access layer and
> >> make it product-aware while all other business-specific layers on top
> >> of it will still work .
> >> I mentioned this in a separate thread but IMO that discussion should
> >> take place in this thread .
> >>
> >> For the moment I've sent a request for comments [1]_ to trac-dev to
> >> explore how much feasible migration to DAO will be . If there's
> >> possitive feedback then it will be great news because we'll be able to
> >> move forward with DB enhancements we need and still merge changes from
> >> Trac trunk .
> >>
> >
> > Here is to hoping but I think we should start thinking what will our
> > strategy be if we do not like the answer.
> >
>
> Yes , we can . However in any case moving forward with incompatible DB
> changes for multi-product support will make merging from Trac trunk a
> really painful experience . That's what my initial message was about
> in first place .
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound]
Proposals/BEP-0003 modified)
Posted by Olemis Lang <ol...@gmail.com>.
On 11/22/12, Peter Koželj <pe...@digiverse.si> wrote:
> On 21 November 2012 18:08, Olemis Lang <ol...@gmail.com> wrote:
>
>> On 11/19/12, Jure Zitnik <ju...@digiverse.si> wrote:
>> > Hi all,
>> >
>> > I updated the BEP-0003 with a (relatively short) draft proposal of
>> > database schema changes required to support multi-product as a first
>> > class citizen in Bloodhound, mostly to start the conversation on this
>> > topic.
>> >
>> [...]
>>
>> Well , I'd suggest not to touch Trac tables for the moment , specially
>> if we want to continue merging changes from Trac trunk into vendor
>> branch .
>>
>
> We already altered the "ticket" table with the multiproduct plugin.
> I would suggest that we multiproductize all entities in the same consistent
> way whatever it is.
>
Yes ? Now I notice .
1. What is that change for exactly ?
2. Why do we need it if we use custom ticket
fields to link products and tickets ?
... please understand that you took the time to review the plugin in
detail while I've been busy with other tasks
;)
>
>>
>> IMO we should consider adding multi-product schema maybe working
>> side-by-side together with Trac's ... maybe not ... and refactor Trac
>>
>
> Can we elaborate on this side-by-side thing?
Keeping our copy of Trac as similar as possible to Trac's , at least
keeping everything above db access layer compatible with it , while we
still use our own tables . That's what I meant . I was thinking about
encapsulating DB access using DAO or something similar ...
In order to succeed in this effort we'll need to work together with
trac-dev for obvious reasons .
> It might be our only option
> but it definitely sounds like horrible
> hack that will haunt BH to the end of it's days.
>
?
> A challenge: How would we model/implement having two milestones in two
> different products with the same name? The same goes for versions,
> components, enum values and wikis.
>
> The interesting Trac db model is not making things easy for us.
>
Sorry , but the starting point is to use DAO exactly for this very
same reason . That'd allow us to introduce our own multi-product DB
schema side-by-side with Trac's (i.e. Trac tables + BH tables ...) and
still make them both compatible at the data access level . That's what
DAO are for .
So I hope you understand why I won't consider answering your question
since it looks like you didn't understand my intention .
>
>> code to use DAO in such a way we can override data access layer and
>> make it product-aware while all other business-specific layers on top
>> of it will still work .
>> I mentioned this in a separate thread but IMO that discussion should
>> take place in this thread .
>>
>> For the moment I've sent a request for comments [1]_ to trac-dev to
>> explore how much feasible migration to DAO will be . If there's
>> possitive feedback then it will be great news because we'll be able to
>> move forward with DB enhancements we need and still merge changes from
>> Trac trunk .
>>
>
> Here is to hoping but I think we should start thinking what will our
> strategy be if we do not like the answer.
>
Yes , we can . However in any case moving forward with incompatible DB
changes for multi-product support will make merging from Trac trunk a
really painful experience . That's what my initial message was about
in first place .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound]
Proposals/BEP-0003 modified)
Posted by Peter Koželj <pe...@digiverse.si>.
On 21 November 2012 18:08, Olemis Lang <ol...@gmail.com> wrote:
> On 11/19/12, Jure Zitnik <ju...@digiverse.si> wrote:
> > Hi all,
> >
> > I updated the BEP-0003 with a (relatively short) draft proposal of
> > database schema changes required to support multi-product as a first
> > class citizen in Bloodhound, mostly to start the conversation on this
> > topic.
> >
> [...]
>
> Well , I'd suggest not to touch Trac tables for the moment , specially
> if we want to continue merging changes from Trac trunk into vendor
> branch .
>
We already altered the "ticket" table with the multiproduct plugin.
I would suggest that we multiproductize all entities in the same consistent
way whatever it is.
>
> IMO we should consider adding multi-product schema maybe working
> side-by-side together with Trac's ... maybe not ... and refactor Trac
>
Can we elaborate on this side-by-side thing? It might be our only option
but it definitely sounds like horrible
hack that will haunt BH to the end of it's days.
A challenge: How would we model/implement having two milestones in two
different products with the same name? The same goes for versions,
components, enum values and wikis.
The interesting Trac db model is not making things easy for us.
> code to use DAO in such a way we can override data access layer and
> make it product-aware while all other business-specific layers on top
> of it will still work .
> I mentioned this in a separate thread but IMO that discussion should
> take place in this thread .
>
> For the moment I've sent a request for comments [1]_ to trac-dev to
> explore how much feasible migration to DAO will be . If there's
> possitive feedback then it will be great news because we'll be able to
> move forward with DB enhancements we need and still merge changes from
> Trac trunk .
>
Here is to hoping but I think we should start thinking what will our
strategy be if we do not like the answer.
>
> .. [1] [RFC] DB access rewritten using DAO or alike. WAS: [BEP-0003]
> Request to reject /ticket/<product prefix>/<sequence ID> routes
> (
> http://old.nabble.com/-RFC--DB-access-rewritten-using-DAO-or-alike.-WAS%3A--BEP-0003--Request-to-reject--ticket-%3Cproduct-prefix%3E-%3Csequence-ID%3E-routes-to34705110.html
> )
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound]
Proposals/BEP-0003 modified)
Posted by Olemis Lang <ol...@gmail.com>.
On 11/19/12, Jure Zitnik <ju...@digiverse.si> wrote:
> Hi all,
>
> I updated the BEP-0003 with a (relatively short) draft proposal of
> database schema changes required to support multi-product as a first
> class citizen in Bloodhound, mostly to start the conversation on this
> topic.
>
[...]
Well , I'd suggest not to touch Trac tables for the moment , specially
if we want to continue merging changes from Trac trunk into vendor
branch .
IMO we should consider adding multi-product schema maybe working
side-by-side together with Trac's ... maybe not ... and refactor Trac
code to use DAO in such a way we can override data access layer and
make it product-aware while all other business-specific layers on top
of it will still work .
I mentioned this in a separate thread but IMO that discussion should
take place in this thread .
For the moment I've sent a request for comments [1]_ to trac-dev to
explore how much feasible migration to DAO will be . If there's
possitive feedback then it will be great news because we'll be able to
move forward with DB enhancements we need and still merge changes from
Trac trunk .
.. [1] [RFC] DB access rewritten using DAO or alike. WAS: [BEP-0003]
Request to reject /ticket/<product prefix>/<sequence ID> routes
(http://old.nabble.com/-RFC--DB-access-rewritten-using-DAO-or-alike.-WAS%3A--BEP-0003--Request-to-reject--ticket-%3Cproduct-prefix%3E-%3Csequence-ID%3E-routes-to34705110.html)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article: