Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAGMZAuO+2N1kvOTsAdtXD1Abr3F6u1Z7m6ozVsoZXansOOb03w@mail.gmail.com>
References: <20121219150559.630A4803B1@bloodhound-vm>
	<CAGMZAuO+2N1kvOTsAdtXD1Abr3F6u1Z7m6ozVsoZXansOOb03w@mail.gmail.com>
Date: Thu, 20 Dec 2012 14:08:04 +0100
Message-ID: 
 <CAHM0gngOMK3TpHXZ2xw=whP-tPcymGZdb_TdqwyLmyPsMpw=iA@mail.gmail.com>
Subject: Re: [Apache Bloodhound] BloodhoundSearch modified
From: Andrej Golcov <andrej@digiverse.si>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Thanks to Olemis to bring this subject into discussion.

> +   * Usage of DB triggers is another alternative
> side note : for some reason Trac-dev are not very fond of triggers ...
> maybe because each DB backend provider implements triggers in a
> different manner
I'm also not a big fan od DB level hooks but we have to take all
possibilities in consideration :)

Talking about index/DB consistency, we have a transactional DB and
non-transactional index. And we need some mechanism to have index as
much as possible consistent to DB in order to avoid often full
re-indexes.

Talking about ticket indexing, I see two problems so far:
 - Version, Component and Product updates are not reflected in events
that can be hooked for index update
 - ITicketChangeListener events are triggered after DB transaction
commit that can potentially cause index inconsistency in case of index
backend is unavailable or process terminated unexpectedly.

IMHO, the most clean solution is adding support for this in Trac core.
The suggestion is to introduce new interfaces such as
ITicketChangingListener, IVersionChangingListener,
IComponentChangingListener etc. that are triggered within
transactional scope. These interfaces are aimed for short running
operations within transaction but not for long running tasks such as
mail sending etc.

The search plugin will hook on these events. When called within
transaction (for example by ITicketChangingListener) the search plugin
can insert a record into new table e.g. index_tasks with changed
ticket id, action name (changed/new/deleted) etc.

Another out-of-transaction task can SELECT FROM index_tasks and
perform real indexing. The task can be executed by cron job or/and
within the same request that changed the ticket.

Uf, a bit complicated, isn't it?
What do you think, does it make sense? Other possible solutions are
collected here:
https://issues.apache.org/bloodhound/wiki/BloodhoundSearch#consistency

What do you think if we contact Trac community with suggestion (and
code) of introducing new interfaces like ITicketChangingListener and
others?

Regards, Andrej