bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <>
Subject Re: Datamodel and data consistency
Date Mon, 29 Oct 2012 07:57:59 GMT
On Sat, Oct 27, 2012 at 11:11 AM, Joe Dreimann <> wrote:

> On 27 Oct 2012, at 04:29, Peter Koželj <> wrote:
> > [...] as a user I surely don't
> > need separate email for each affected ticket, just the one saying that
> > product or milestone or whatever has changed would be enough.
> >
> > Peter
> Fully agree.
> - Joe

Ok, if I try to recap all this and try to think about what it all means:

We agree that data model as is needs fixing (it is not enterprise or
distributed environments friendly). Some of the fixes are local (like
multiproduct plugin) for other it seems that we should just do them through
BH and offer the solution to Trac. But what are the implications?

1. We would deviate from standard Trac quite a bit with a risk that our
changes are accepted with a big delays or even rejected. Merging in new
Trac versions could become a nightmare. Would we be willing to stay on Trac
1.0 for ever? And we would have to go from "...on the shoulders of Trac..."
to "... not compatible with Trac...".

2. With the lack of data abstraction or data access constraints on a plugin
level, plugins depend on this same database model. We will lose
compatibility with most of the plugins that relay on the Trac database
schema. And if we would insist on using some of the existing plugins for BH
functionality we would be forced to fork them (see next point).

3. Adding data consistency on database level will break current plugin
model. Data imports and schema upgrades become nontrivial and would require
special inter plugin protocol to synchronise all that. Asking plugin
authors to support two different data models and two different plugin
models seems a bit much and would probably mean two different plugins (trac
and BH) for the same functionality. So do we want entreprise DBA support or
plugin authors support?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message