Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gary.martin@wandisco.com
 designates 209.85.214.47 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: 
 <CAJSKAsiJXpGyGFgm9a=ZEqDxPOVzqsLkzgtcatWGXYo+5cFVVw@mail.gmail.com>
References: <20121119163545.55EF9808A7@bloodhound-vm>
 <50AA605B.1050007@digiverse.si>
 <CAGMZAuMaAEv3=R8wLMU7Xobnf8eWybNbTaz1JdrL+ehyQ0E5Og@mail.gmail.com>
 <CAJSKAsi+R_Gx6QLP--M-uR+H_JCaHkAZLbvPLOGRNXgRVjGumQ@mail.gmail.com>
 <CAGMZAuMByiLeGePe+jg57RPVQczoCdfaqj2LtNcQ71J4XL-dNw@mail.gmail.com>
 <CAJSKAsiJXpGyGFgm9a=ZEqDxPOVzqsLkzgtcatWGXYo+5cFVVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound]
 Proposals/BEP-0003 modified)
From: Gary Martin <gary.martin@wandisco.com>
Date: Thu, 22 Nov 2012 14:49:04 +0000
To: bloodhound-dev@incubator.apache.org,=?UTF-8?Q?Peter_Ko=C5=BEelj?=
 <peter@digiverse.si>
Message-ID: <f189967f-ad24-42a1-a86b-0fed21d4df36@email.android.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" <peter@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 <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:
>>