Unfortunately we don't have a general purpose constraint system in Jena, but I could definitely see the benefit of one, especially if you wanted to use an ontology for constraint validation, as Pellet is able to do.
As another option to the suggestions from Claude and Andy: don't attempt to store the description string. Denormalizing the data in this way leads to exactly these problems. I am surprised that generating the description value at the time of query is that expensive. I wouldn't think it bad until you started getting into the 1000s or 10000s of relationships for each subject. In that case, as this appears to be for human consumption, perhaps it is reasonable to put a LIMIT on the number that are appended to the string? Or instead return a count? Hope this helps! -Stephen On Thu, May 31, 2012 at 1:37 AM, Andy Seaborne <[email protected]> wrote: > Eric, > > There are two way I can think of enforcing such a condition. Claude's > mentioned listening to graph changes, whereby you can fix up the data after > the change has been made. > > To assist that you could provide your own GraphStore (just wrap the one you > actually want to update) and it has calls to startRequest and finishRequest > so you can know which points make the start and end of the update request. > > There is an event sent to the GraphEventManager to signal the start and end > of an update as well (called by startRequest/finishRequest). Except > checking I see these are not called for TDB - fix just applied. > > startRequest() really should take the Request object as an argument - again, > added startRequest(Request), with a deprecation cycle to remove > startRequest(). > > If you want to enforce a condition before hand by checking the validity of > the update to see if it looks like it does include a :description in the > INSERT part, you can catch the update request object by adding your own > UpdateEngineFactory that passes the real request to an underlying > UpdateEngineFactory but gets to look at every request first. > > Any feedback would be great - this is a reasonable thing to want to do but > it does look more complicated than it need be. In fact, what might be a > good idea is to plan out update request lifecycle have and specific plug-in > points. > > >> If not, I gather best practice would be to provide a separate tool >> for editing content which would not expose a sqarql update facility >> to end users.... > > > To be honest, if the condition is important then I'd do something like this > - have code that generates consistent updates. SPARQL is a general purpose > tool - packaging it up to give app-specific functionality seems like a good > design to me. > > Andy >
