Rob van Maris <[EMAIL PROTECTED]> wrote: > <Michiel Meeuwissen:> > > > > Query project is usable front-end now (mmci / taglib). After > > making a 'bridge' version I have some questions about the > > core version. E.g.: > > > > - the 'NodeQuery' of bridge is more generic than the > > NodeSearchQuery of core, and > > I wonder if the core version should not be an interface. > > Not sure I understand this... > Why should NodeSearchQuery be an interface?
Well, the bridge version of 'NodeSearchQuery' I stretched a bit. Bridge's NodeQuery means a query returning all and only fields of one of the steps, meaning that in practice it is returning 'real' non-cluster nodes. This is useful to implement getRelatedNodes and cognates (so, sorting, constraining on other steps that the ones actually returned <mm:relatednodes type="news" role="posrel" orderby="posrel.pos" ...). So, a 'NodeQuery' is a query fit for functions which do not return ClusterNodes. The 'core' version of NodeSearchQuery does however not allow for adding steps and so on, so I for now cannot simply wrap it in the bridge. In fact, I find it less usefull as bridge's NodeQuery. And additionally, if NodeSearchQuery would follow this idea and also became an interface then, the bridge version could simply wrap it (for security) and implement it too and could also pass itself to the core without to much hassle. > In order to use the aggregating function MAX() on the field price, it's > required to use GROUP BY on the remaining field(s), i.e. article. This > requirement is reflected by the available aggregation-types in > aggregating queries. Ah ok. I'll try that some time. > > > - Also there is no way to access database functions. > > This is only partly true. The basic queryhandler does not support these > ase these are highly database-specific. (With the exception of > LOWER/UPPER, which is used behind the scenes to enable case-insensitive > string comparison.) For this reason database functions are used nowhere > in the MMBase core at present. > > The only sensible use of database functions I can think of is in > constraints, where this improves query performance. > This is precisely what the SearchQuery extension mechanism is designed > to do. New constraint types can be introduced and the database specific > sql-handlers can be extended to handle these when possible. But almost > always at the cost of losing database-portability. Yes I understood the problem, but also that they can ideed be useful in constraints and/or sortorders. I wonder however if it would not get a bit complicated then. If I need to compare a field to the absolute value of another field, do I need to implement an CompareAbsoluteFieldConstraint? CompareSinusMinusCosinusFieldConstraint? Field1MinusField2SortOrder? I gave examples of simple aritmetic and mathematics because I do suppose they are supported by most databases (at least for the ones I checked (mysql, postgresql, hsql) it seems very straight-forward) Wouldn't it be more simple to use existing implementations but let them not only accept 'real' fields? Or perhaps we can compromise by extending each one time by a version accepting these kind of expressions (remains the problem how to model those expressions..)? Only brain-storming.. Michiel -- Michiel Meeuwissen Mediapark C101 Hilversum +31 (0)35 6772979 nl_NL eo_XX en_US mihxil' [] ()
