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
