Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olemis@gmail.com designates
 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <508E57C9.5000809@wandisco.com>
References: 
 <CAKE9Bs-8vonCB7idTJGLAYd=1MmBYxQwRVcYkeW3KSLWg7-dZA@mail.gmail.com>
	<CAPt9QwT+kmebqzhw-kxZtbdX5nwBRTUtQOpqOro6gGOSPCnS9A@mail.gmail.com>
	<CAKE9Bs-_49FFBn7nm9uNXSNYGFfRJ-QsTKgxadL+-CaNTpBmaw@mail.gmail.com>
	<CAGMZAuMH_bjnUJf-Y3xjCmTkk7OT0VFdcfmvgcFP6ncSL706Lg@mail.gmail.com>
	<508A4CAB.3070106@digiverse.si>
	<CAPt9QwS6E7tVEHHQZ8PZy37rRs77=LiL-RbjFJ5MhTQMBTU2Ew@mail.gmail.com>
	<CAGMZAuO6RVoTKk7RyqJC+n9fNmHNJ18XeV5_U9OMX2P+NX+4yw@mail.gmail.com>
	<CAKE9Bs_Dw9Y=sF_41x=9zHFortiUcBqwu8qBNiZZYRfA4zeP1A@mail.gmail.com>
	<E26FC9A5-6750-4552-9332-05C8D03D1A1A@wandisco.com>
	<CAKE9Bs-3682OUtbvhfke_tXZVuTt4_ZVf2QdC6b82QCkbLr8=A@mail.gmail.com>
	<508E57C9.5000809@wandisco.com>
Date: Mon, 29 Oct 2012 13:03:17 -0500
Message-ID: 
 <CAGMZAuMt_wOptm1ZV59aeGCkNPfoDWPEbyZCZSX1hJi1M7LK0w@mail.gmail.com>
Subject: Re: Datamodel and data consistency
From: Olemis Lang <olemis@gmail.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On 10/29/12, Gary Martin <gary.martin@wandisco.com> wrote:
>
[...]
> I don't want to be moving away from Trac [...]
>

+1 ... though I'd really like to see some gradual transition onto an
ORM in the middle handling DB access e.g. like SqlAlchemyIntegration
[1]_ .

> It would certainly be difficult for plugin authors to support multiple
> plugin models.
>
[...]
>
> To make that
> work we would probably need to make sure that changes are generally
> transparent and always easy to convert [...]
>

+1

> Going back to the problem with multiproduct, I'm happy to see us
> swapping to using the immutable product prefix. I am not yet convinced
> of the argument of providing an extra field for the convenience of
> allowing us to easily make the prefix mutable.

The prefix must not be mutable if it will be used to identify product
resources . Notice that in Trac there are other relations outside DB
schema , the most notorious being TracLinks .

> Withholding the ability
> to change the prefix will be simplifying for the users of the system so
> that they do not have to get used to referring to tickets through a new
> prefix on the whim of another user. While we could provide the ability
> for the old prefix to continue to be usable for identifying the
> appropriate resource under the new prefix, the potential confusion in
> discussions of tickets just seems unwarranted. The workaround exists of
> creating a new product and moving the tickets into it.
>

+1 . Changes to product prefix should be an admin task carried out
using external scripts , trac-admin commands or alike ...

> As for the question of notifications, I agree that we don't want
> multiple emails associated with a a change of product but I think it
> would be nice for resources that were associated at the time of the
> change to be able to report that the event has happened. On the other
> hand, the activity feed should really only show one event at any given
> scope.

At present batch modifications contribute a single event to the timeline .

> I am not convinced that that the bulk modify apparatus is the
> correct approach for this in the long term.
>

It looks handy to reuse existing batch modifications .

.. [1] Trac SQLAlchemy Bridge
        (http://trac-hacks.org/wiki/TracSqlAlchemyBridgeIntegration)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: