incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound] Proposals/BEP-0003 modified)
Date Thu, 22 Nov 2012 13:32:03 GMT
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 <olemis@gmail.com> wrote:

> On 11/22/12, Peter Koželj <peter@digiverse.si> wrote:
> > On 21 November 2012 18:08, Olemis Lang <olemis@gmail.com> wrote:
> >
> >> On 11/19/12, Jure Zitnik <jure@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:
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message