On 22 November 2012 18:08, Olemis Lang <[email protected]> wrote: > On 11/22/12, Gary Martin <[email protected]> wrote: > > "Peter Koželj" <[email protected]> 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: >
