Hmm. Supporting something like "a<b" would really go beyond supporting
FIQL... May be we indeed can support plain "=" only.
We already have a property called "search.use.plain.queries", this
applies to a case where we have
?a=b&cFrom=2&cTo=3
This is not a FIQL expression, but we can use these property to support
those cases where the clients are written to support plain non-FIQL
queries but we want them routed to SearchCondition API.
Now, if we have a case when an expression is embedded within a path
segment, then we may want to support this minor optimization, to support
a single '=' only, this may also let people simplify slightly in the
case when a "search.use.all.query.component" property is set:
?a==b;a=lt=b
I'll add a property "search.support.single.equals.operator": note I'm
doing it to make "search.lax.property.match" more useful :-), but to
support slightly simpler expressions, and, in your case, a possibility
of passing non-FIQL parameters alongside the actual expression
Sergey
On 18/07/13 13:00, Sergey Beryozkin wrote:
Hi
On 18/07/13 09:17, nikosdim wrote:
Hi
I did some debugging in my code and I found out that the
NullPointerException is caused because the records=20 does not have a
double
== .FIQL recognizes only == and not =.
I believe NPE is caused by the fact your code does not check a returned
SearchCondition for null
When I changed it to records==20 then
the "search.lax.property.match" worked just fine and ignored the
records==20
successfully.
So as you said single = must be supported in order for the
"search.lax.property.match" to be useful.
It is not quite the same conclusion that I came to.
The goal of "search.lax.property.match" is to support the case where a
bean class has no property setters for a given property name+value pair
found in the FIQL expression.
I don't think we can say that we need to support, for example
"records<>20", where '<>' is a hypothetical 'not equal to' operator
which is not part of FIQL, for "search.lax.property.match" be useful.
The problem is that your expression is not a valid FIQL hence the whole
issue arises, which would also be the case if we used something else,
like '<>' operator, etc.
However I as said IMHO it can make sense to support a consistent set of
simplified expressions to support a "plain query"-like case, for
example, we can have "author=Peter;records=20", or
"author=Peter;records<20", but not a mix of FIQL & non-FIQL expressions,
as in your case
Cheers, Sergey
Thanks
--
View this message in context:
http://cxf.547215.n5.nabble.com/Where-to-put-contextual-property-ignore-matrix-parameters-true-tp5730881p5731078.html
Sent from the cxf-user mailing list archive at Nabble.com.
