On 11/04/2008, Rickard Öberg <[EMAIL PROTECTED]> wrote: > > Alin Dreghiciu wrote: > > * matches: Property<String> matches a regexp. Or shall we call it > "LIKE"? > > I think "LIKE" has semantics from SQL that means "string contains" > rather than regexp. matches is much better, and very useful.
yes, I'd choose "matches", as it matches the Java API ;) (LIKE does suggest SQL semantics, which are different) > * in: Property<T> in (T...) = evaluates to true when property value is > > any of the values in array > > +1 > > > * between: Property >= minValue && Property <= maxValue > > Isn't this just syntactic sugar for "ge and le"? Might still be useful > though. I'd favour a simple query API that can easily be composed, rather than a rich set of potentially overlapping operations - "in" is useful as a set operation, not sure about "between" we could provide a library of builder methods later on that provide compositions like "between", or interpretation of mathematical ranges like "[a,b)" etc... > Also, till now there is no support for ManyAssociation(s). Question is > > what kind of filtering shall we support for ManyAssociation(s)? > > This can be useful 9yet I do not know how easy can be implemented): > > > > * isEmpty, isNotEmpty > > * sizeEq, sizeNotEq, sizeGe, sizeGt, sizeLe, sizeLt > > * contains: ManyAssociation collection contains a certain entity if "size" is a property of a ManyAssociation then couldn't you use the existing qery operations, applied to the "size" property (just from a conceptual perspective, not thinking about if this is possible with the current code) The main ones I can think of are contains and isEmpty/isNotEmpty. Not > sure how useful the size* ones are. Anyone with practical experience of > needing these? you could overload "in" and use that for contains when dealing with associations, as it also deals with set-style membership isEmpty and isNotEmpty could again be represented as querying the "size" property (though there is a possible performance benefit with them as they don't query the exact size...) imho keep the query API simple for now, we can always add extra operations as use-cases come up, but it's more difficult to remove operations later on... /Rickard > > > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Cheers, Stuart
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
