incubator-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 17:08:17 GMT
On 11/22/12, Gary Martin <> wrote:
> "Peter Koželj" <> 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
>>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
>>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
>>and parse incoming SQL to rebuild them with new model specifics by
>>product prefix from url/ui session. Plugins that would actually need DB
>>operations through multiple products would use some newer multiproduct

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

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.


> 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



Blog ES:
Blog EN:

Featured article:

View raw message