bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound] Proposals/BEP-0003 modified)
Date Thu, 22 Nov 2012 06:58:32 GMT
On 11/22/12, Peter Koželj <> wrote:
> On 21 November 2012 18:08, Olemis Lang <> wrote:
>> On 11/19/12, Jure Zitnik <> 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 .



Blog ES:
Blog EN:

Featured article:

View raw message