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 18:00:19 GMT
On 22 November 2012 18:08, Olemis Lang <olemis@gmail.com> wrote:

> On 11/22/12, Gary Martin <gary.martin@wandisco.com> wrote:
> > "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.
>
> 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 .
>

Sorry if I missed or misunderstood something. I am still trying to figure
out wether we are thinking the same thing or not. Something definitely got
lost on the wire :(

By "whereas we adopt a completely different DB schema" are you thinking BH
and installed plugins do not use Trac tables at all as in create complete
new schema or a BH schema as a complementary solution? An example for let's
say "milestone" would clear things up.

Also I imagine that just fixing Trac with DAO/ORM is not enough, what about
all the plugins on Trac Hacks?


>
> >>As I pointed out that some aspects of the db model and multiproducts
> >>can
> >>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
> >>like
> >>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
> >>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.
> >>
>
> 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.
>

Some input on that would be welcomed. We could focus on that problems first
to see if a fresh set of eyes can find a solution and avoid researching for
days only to come to the same conclusions.


>
> >> and no need for DAO if Trac rejects
> >>them.
> >>
>
> 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.
> >
>
> +1
>
> > 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
>         (http://trac.edgewall.org/wiki/TracDev/Proposals/TracRelations)
>
> --
> 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