On 21/10/13 21:07, Jim Talbut wrote:
On 21/10/2013 10:18, Sergey Beryozkin wrote:
I believe the JPA2 way is to use either JPA2 Tuple or capturing
beans/arrays which will filter the 'username' & 'enabled' properties
at JPA/DB level, the JPA2 section has a couple of examples and
JPATypedQueryVisitorTest has few more (to do with different styles of
shaping the output), I'd probably go for using Tuple.
If you prefer to use a custom UserFilter then I guess you'd need to use
JPATypedQueryVisitor<User_JpaImpl> and then filter the result list
with the filter afterwards
Thanks, I think I'm going to go with using another visitor just to do my
validation, and then use the simple TypedQuery - any other approach
seems to create more complexity (for my scenario) than it's worth.
The metadata can be generated with the JPA impl plugin, the plus - the
faster retrieval times I guess
Is there a reason why any errors in the parsing are silently swallowed
in SearchContextImpl.getCondition():
if (theExpression != null) {
try {
return parser.parse(theExpression);
} catch (SearchParseException ex) {
return null;
}
} else {
return null;
}
Right, originally I thought that typically, if one goes and query some
web site and mistypes a query name then one would still get some default
OK response, as opposed to some 400.
So if you get 'null' then assume that the default representation is to
be returned, given that the query parameters are usually optional anyway.
However, I agree this approach may have its limitations, I think that
for 3.0 only, we need to push the responsibility a bit higher to the
application code, the good practice would still most likely be to
proceed with returning a default rep, but may be the application code
will decide to do something else
Cheers, Sergey
Thanks again.
Jim
