On 10/25/12, Branko Čibej <[email protected]> wrote: > On 25.10.2012 09:02, Olemis Lang wrote: >> On 10/24/12, Branko Čibej <[email protected]> wrote: >>> On 25.10.2012 04:52, Olemis Lang wrote: >>>> On 10/24/12, Peter Koželj <[email protected]> wrote: >> [...] >>>> This is what Trac-dev should be working towards regarding relations of >>>> any kind between resources . >>>> >>>> http://trac.edgewall.org/wiki/TracDev/Proposals/TracRelations >>> That page was last updated 4 years ago. Are you seriously suggesting >>> that referring this question to trac-dev@ will, after all this time, >>> have any measurable effect? >>> >> yes , there are recent conversations where it was cited , especially >> regarding post-Trac 1.0 schedule . Indeed multi-project proposal [1]_ >> is another example , last updated 3 y ago , and there's some recent >> work on that direction [2]_ . It's worth to mention that target t-h.o >> plugin seems to be intended to be incorporated into Trac at a given >> time in the future . The spec is also the starting point (and >> inspiration) for our own initial approach towards multi-product >> support . > > I think it's a better approach to just implement these things the way > they should be done, then propose patches to trac-dev. The other way > around is going to take forever. >
+1 ... that's why we have our own development branch towards this goal > I won't describe the headache I got when I tried to reconcile the > TracRelations proposal with relational data modelling principles, or > abstraction layering principles. > well , it's more similar to other techs like non-relational DBs , BPMS , ... indeed afaicr it is somehow based or some parts inspired on some Java BPMS ... don't recall the details though . Such decoupled/generic/abstract DB scenarios are quite common these days ... /me not saying they are always right , though -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
