On 1/11/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote: > IMO, this should be handled by the application and not the repository. A > repository might allow to set constraints on the a binary property, but > this would be independent of indexing that property.
when you say "this should be handled by the application", what specifically do you mean? 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? > 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. > there are several questions that arise: > - will a transaction fail if this happens? i don't use transactions. so i hadn't considered this question. > - 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 ;)
