Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of castagna.lists@googlemail.com
 designates 74.125.82.43 as permitted sender)
Message-ID: <4E6F88B0.6030705@googlemail.com>
Date: Tue, 13 Sep 2011 17:45:36 +0100
From: Paolo Castagna <castagna.lists@googlemail.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: jena-dev@incubator.apache.org
Subject: Re: Jena and PostGIS =?UTF-8?B?KMOgIGxhIExBUlEp?=
References: <4E6F41B8.8050600@oucs.ox.ac.uk> <4E6F6E49.50502@googlemail.com>
 <4E6F7355.6090408@oucs.ox.ac.uk> <4E6F867C.10506@epimorphics.com>
In-Reply-To: <4E6F867C.10506@epimorphics.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Andy Seaborne wrote:
> 
> 
> On 13/09/11 16:14, Alexander Dutton wrote:
>> Does Fuseki/TDB currently fire off some kind of signal when updates
>> happen?
> 
> Handling of events isn't consistent yet.
> 
> Each GraphStore sees startRequest()/finishRequest() around a SPARQL 
> Update.  That should be roughly what you are looking for, I guess.
> 
> There isn't an event down to the level of each quad added or removed.

This might be easier for developers (since they don't need to parse
the SPARQL Update request).

But, maybe there is a good reason why there isn't an event down to the
level of each quad added|removed. Let me guess: performances? :-)

> Now is a good time to work out the details of what's wanted.  The 
> original jena events mechanism works well but places the events on an 
> object, so only objects supporting the event interface participate. 
> Makes global or general events unnatural as well.

Yep.

 From a LARQ or similar point of view (i.e. third party custom indexes)
it would be extremely easy to be able to be notified for each quad
added or removed.

This way and external index can be kept up-to-date as data changes.

Often, there are little changes and it's a waste of time/resources
(and it require manual intervention or automated scripts) to re-index
everything just because a small percentage of data has changed.

> 
> The package org.openjena.atlas.event (in ARQ) is my attempt to retain 
> the light weigh event mechanism but decouple it from an event interface. 
>  You can send events relating to objects without the objects participation.

I'll have a look (and see if I can use that in LARQ).

Thanks,
Paolo

> 
>     Andy