> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michiel Meeuwissen > > I only have a few small issues wandering in my head: > - NodeSearchQuery did not seem very useful, bridge version > 'NodeQuery' does > not even (always) wrap it currently. And it is not an interface, so > NodeQuery also cannot simply be a NodeSearchQuery.
NodeSearchQuery provides a recipe to create a specialized query, i.e. one that retrieves real nodes (as opposed to virtual nodes). The org.storage.search interfaces, on the other hand, define the interaction between queries and queryhandlers. >From the point of view of the queryhandlers, there's no need to differentiate between NodeSearchQueryies and other, more general queries, so there is no separate interface for it. > - I found it odd that 'aggregation' is a field. This simply reflects that in an aggrageted query, each field is either aggregated or grouped by. Not my invention, but plain SQL. > - I think the opposite of 'greater' is 'smaller' and not 'less'. (In > FieldCompareConstraint) Yeah right. > don't now how important these are, but I've said it at least! You're welcome! > Furthermore I do think that perhaps this bridge version of > SearchQuery is not 'ready'. Mainly it needs review, and > people should perhaps check if it actually is sufficiently > complete and user-friendly. One thing I'm concerned about is how bridge interfaces are finding their way in core classes. I think this should be avoided at all costs. Rob van Maris Technical Consultant Quantiq xmedia & communication solutions Koninginneweg 11-13 1217 KP Hilversum T +31 (0)356257211 M +31 (0)651444006 E [EMAIL PROTECTED]
