Custom filters, fields and sorts

[GoogleCodeExporter]

This is a much-requested feature.

Here is an idea for how it might work... For all the below any reference to a 
field must be surrounded by curly braces ({}) in order for the framework to 
detect it and properly integrate it into the query.

**FILTER**
Filter.custom("{myLongProperty} like %4780%");

Also allowing

Filter.custom("{myLongProperty} like ?1", "%4780%");

where any number of parameters may be specified using ?1, ?2, ?3, etc. within 
the custom query string.

Other uses for the filter would be:
Filter.custom("{myLongProperty} > {myOtherProperty} + 1");
Filter.custom("1 = 1");
Filter.custom("?1 > ?2", 4, 2);
Filter.custom("{id} in (select pc.cat_id from popular_cats pc. where pc.color = 
'blue')");

**FIELD**
No changes to current field interface. It would be used like this...

new Field("{firstName}||' '||{initial}||' '||upper({lastName})");
new Field("({top} - {bottom}) / 2", Field. OP_MAX);

**SORT**
No changes to current sort interface. It would be used like this...

Sort.asc("cast({employeeno} as integer)");
Sort.desc("abs({prop1} - {prop2})");

The way to specify that the value is not just a property in a field or sort is 
to include any character that wouldn't be in a property (for example: 
parenthesis, space (not at the beginning or end because it gets trimmed), curly 
braces). So if there's a constant, it could be wrapped in parentheses to 
specify that it is not a property (ex: "('my_constant')").

Additionally, to tighten down security just a little bit (although we don't 
really have a robust security scheme yet), each Search will have properties for 
whether or not to allow custom sorts, fields and filters. The case for this is 
when searches are created directly from user input, in which case it might be 
necessary to lock down certain entity types or properties from being accessed.

Original issue reported on code.google.com by dwolvert on 13 Nov 2010 at 3:18

[GoogleCodeExporter]

Issue 72 has been merged into this issue.

Original comment by dwolvert on 13 Nov 2010 at 3:19

[GoogleCodeExporter]

Original comment by dwolvert on 25 Feb 2011 at 2:01

• Added labels: Milestone-Release1.1.0

[GoogleCodeExporter]

To provide better protection against accidental or intentional HQL/JPQL 
malformities and injection attacks, I think we should require more explicit 
indication of custom expressions in Fields and Sorts.

For fields, require the OP_CUSTOM operator. If max or count or other 
aggregating operator is required, it will need to be included in the expression 
manually. Examples...

new Field("{firstName}||' '||{initial}||' '||upper({lastName})", 
Field.OP_CUSTOM);
new Field("max(({top} - {bottom}) / 2)", Field.OP_CUSTOM);

For Sorts, it's a bit trickier. There is no operator so we'll add an additional 
isCustom flag. This will be the first parameter of constructors. Examples...

new Sort(true, "cast({employeeno} as integer)");
new Sort(true, "abs({prop1} - {prop2})", true);
Sort.ascCustom("cast({employeeno} as integer)");
Sort.descCustom("abs({prop1} - {prop2})");

Original comment by dwolvert on 28 Feb 2011 at 1:34

[GoogleCodeExporter]

Original comment by dwolvert on 28 Feb 2011 at 4:36

• Changed state: Started

[GoogleCodeExporter]

Original comment by dwolvert on 1 Oct 2011 at 10:58

• Changed state: Fixed