incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
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 <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
View raw message