jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: handling indexing failure
Date Wed, 11 Jan 2006 16:48:52 GMT
Brian Moseley wrote:
> when you say "this should be handled by the application", what
> specifically do you mean?

I think it shouldn't be the responsiblity of the index to check for 
validity of data. this should be somewhere further up. either in the 
application that is using the JCR API or the repository may support a 
constraint on a binary property.

e.g. jackrabbit could provide some kind of constraint for binary 
properties that says: this property must contain utf-8 text and conform 
to a certain DTD or XML Schema. well, this is certainly not available at 
the moment, but IMO this is where such a check belongs to.

> to be clear, my node has a binary property that stores an icalendar
> stream. our text/calendar text filter parses that stream into
> icalendar components, properties, and parameters and creates a
> TextFilter.TextFilterIndexString for each. then the application can
> construct extremely simple jcr queries to see if a node has, say, the
> icalendar SUMMARY property without the node actually having a jcr
> property representing that.
> 
> are you suggesting that the application should maintain its own index
> of icalendar data outside of the repository and provide its own query
> engine for finding resources by their icalendar properties?

not at all. you are using the text filter exactly how I envisioned it. 
using 'virtual properties' ;) that are only available in the index. but 
to me it just doesn't feel right that the index should be responsible 
for checking the validity of content.

>>tobi already mentioned that such a feature could be implemented with
>>something like a custom filter. but again that would be on a higher
>>level. and not deep down in the index.
> 
> 
> sorry, i miscommunicated. i didn't understand that text filtering and
> indexing were separate layers. to me, it's all in the query package ;)
> the component that i'm having trouble with is a custom TextFilter.

ah, and also miscommunication from my side... I wrote custom filter, but 
what I was tring to say is custom constraint. JCR allows to define 
constraints on properties. currently only basic constraints are 
specified by jcr-170: value ranges for long properties, etc.

as I mentioned above, the validity should be handled by a constraint 
that is checked in the *transient* layer of the repository.

>>- observation is triggered after changes are made persistent, we would
>>need to roll them back in some way. the current persistent manager api
>>does not allow that.
> 
> that's what i meant when i said the application would have to
> explicitly remove the node upon catching this unchecked exception. it
> would be doing a manual rollback. of the node save. yeah, yuck. i
> don't like it either. that's why i'd like for my custom TextFilter to
> be able to veto the operation ;)

well, to me it seems much easier to do this kind of constraint check 
earlier in the transient layer. because then the repository does not 
have to do any rollback, but will simply not save the transient changes.

I agree that we need vetoable listener and will finally implement it for 
jsr-283 but this will look very different from what we currently have 
with the text filters. text filters are not meant to do checks there! 
sorry...

regards
  marcel

Mime
View raw message