Rob van Maris <[EMAIL PROTECTED]> wrote: > > -----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).
Jes, that it the 'NodeQuery' of bridge too, but that does not mean that it cannot contain more then one step. 'NodeQuery' of bridge means only that it returns 'real' nodes, no matter how complex the query will be after the 'FROM'. Since NodeSearchQuery cannot do this, NodeQuery cannot optimally use it. > 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. The bridge's NodeQuery is an interface which means that I can do 'instanceof NodeQuery' to check it the result presents real nodes. This I can now not do in core, unless I supply the bridge's Interface, which seems ugly. Of course this differnce is caused by the fact that the bridge's query interfaces are targeted more at filling and passing to core, rather then to the query handlers. I understand that it does not matter for the QueryHandlers, but I wonder if what I found useful in bridge (taglib e.g.) cannot be useful elsewhere too. > > - 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. Of course. I perhaps would expected to be it an extension or specialization of a normal query. A query is aggregated or it is not, I found it strange that it looks like a mutable property. Perhaps the same as with this nodequery/query differnce. In bridge I want to enforce that e.g. an argument is an AggregatedQuery: AggregatedResult someFunction(AggregatedQuery q); NodeList someFunction(NodeQuery q); ClusterNodeList someFunction(Query q); // well, ClusterNodeList does not exist, but the concept is very imaginable.. which is not possible now, because I did't want to deviate from core also here. Now the only thing you can do is throw an exception if the query happens to be of the wrong type, which is a pitty, because if it would have been an interface, the error could have been found compile-time. > > > 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. I think that might be wrong then. Bridge's Query is also a SearchQuery so I think I didn't bother and the object itself is passed, and not the object which it might be wrapping. That perhaps can simply be solved by doing 'query.getQuery()' here and there rather then 'query' simply, but I think all methods of the SearchQuery interface are wrapped directly, so there should be no functional difference. It does give though a bit of performance overhead because of the extra function calls (which also may be solved by finalizing those wrapper methods), which might be a reason to change something. I'm not sure that this is what you mean? Why do you think it should be avoided? Michiel -- Michiel Meeuwissen Mediapark C101 Hilversum +31 (0)35 6772979 nl_NL eo_XX en_US mihxil' [] ()
