You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Szu-Yu Wang (Created) (JIRA)" <ji...@apache.org> on 2012/04/03 03:25:22 UTC
[jira] [Created] (CXF-4221) FIQL visitor to return a generic
instead of String
FIQL visitor to return a generic <K> instead of String
------------------------------------------------------
Key: CXF-4221
URL: https://issues.apache.org/jira/browse/CXF-4221
Project: CXF
Issue Type: Improvement
Reporter: Szu-Yu Wang
It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Sergey Beryozkin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Beryozkin updated CXF-4221:
----------------------------------
Component/s: JAX-RS
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Szu-Yu Wang (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248503#comment-13248503 ]
Szu-Yu Wang commented on CXF-4221:
----------------------------------
was trying this yesterday. getSearchCondition will pass the CriteriaQuery to the parser, and the bean inspector will use that class to set the properties. so I don't think this works.
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250582#comment-13250582 ]
Sergey Beryozkin commented on CXF-4221:
---------------------------------------
Hi, thanks for this effort, here are some comments.
In the code example, SearchContext is completely bypassed, searchContext.getSearchExpression() is a utility method which is indeed can be handy but it's effectively the same as providing a JAX-RS QueryParam("_s"). The idea behind SearchContext (and SearchCondition + SearchConditionVisitor) is to completely hide the fact it is a FiqlParser that is being used to parse a given search expression, this way it is possible to transparently manage different search languages, something different to FIQL for example.
To be honest, I do not see why FiqlParser should depend on "javax.persistence.criteria CriteriaBuilder,
Predicate, Root".
I'm interested in exploring the new options for making the Search extension be more useful, but I'd like us to think of different options.
First let me suggest that we do not deal with the nested properties, which require the use of beanutils, it is a different issue altogether, so we can return to it later on.
The issue at hand is how to make it easier to adapt the search expressions to JPA handlers (CriteriaBuilder, Predicate, Root, etc) but *without* having to introduce the javax persistence dependencies directly into the FIQL parser, rather I'd prefer to introduce something like JPACriteriaVisitor or something like that.
SearchConditionVisitor has a 'getResult()' method returning String.
JPACriteriaVisitor may have this method unimplemented but offer it's own
getPredicate() method and be initialized with CriteriaQuery<Merchant> & Root, etc.
Can you consider prototyping such a visitor ? After that it will be easier for me to see what can be pushed to the core Search code to simplify the code for the JPA visitor
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
> Attachments: FiqlParser.java
>
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4221) Support FIQL JPA Visitors
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Beryozkin updated CXF-4221:
----------------------------------
Fix Version/s: 2.6.2
Assignee: Sergey Beryozkin
Summary: Support FIQL JPA Visitors (was: FIQL visitor to return a generic <K> instead of String)
> Support FIQL JPA Visitors
> -------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
> Assignee: Sergey Beryozkin
> Fix For: 2.6.2
>
> Attachments: FiqlParser.java
>
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Szu-Yu Wang (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Szu-Yu Wang updated CXF-4221:
-----------------------------
Attachment: FiqlParser.java
I copied your FiqlParser code, used apache commons beanutils for the property class resolution, and had ASTNode.build() return a criteria query.
It'll need some work to make it suitable, and I don't know about how you feel about a dependency on beanutils, but if you can use any part of this, feel free.
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
> Attachments: FiqlParser.java
>
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245120#comment-13245120 ]
Sergey Beryozkin commented on CXF-4221:
---------------------------------------
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
Usually the users would do SearchContext.getSearchCondition(MyClass.class) and then use the resulting search condition to select the matching MyClass instances.
The goal of SearchConditionVisitor is to accumulate a language specific (SQL, etc) representation of the FIQL query which can be fed directly to the external db/storage systems.
what introducing K to SearchConditionVisitor<T, K> help with ? Can you explain please and prototype some example code ?
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
Possibly not the best name, nonetheless consider it the result of the SearchConditionVisitor visiting individual SearchConsitions and transforming them all into a language specific predicate/filter
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Reporter: Szu-Yu Wang
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Szu-Yu Wang (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250426#comment-13250426 ]
Szu-Yu Wang commented on CXF-4221:
----------------------------------
and the code to use the attached FiqlParser:
{noformat}
public List<Merchant> getMerchants(SearchContext searchContext) throws DataNotFoundException {
try {
String searchExpression = searchContext.getSearchExpression();
CriteriaBuilder builder = em.getCriteriaBuilder();
CriteriaQuery<Merchant> cq = builder.createQuery(Merchant.class);
Root<Merchant> root = cq.from(Merchant.class);
Predicate pred = new FiqlParser<Merchant>(
Merchant.class).parse(searchExpression, root, builder );
cq.where(pred);
TypedQuery<Merchant> q = em.createQuery(cq);
List<Merchant> results = q.getResultList();
return results;
} catch (FiqlParseException fpe) {
throw new DataNotFoundException(DataExceptionEnum.DATA_NOT_FOUND);
}
}
{noformat}
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
> Attachments: FiqlParser.java
>
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4221) Support FIQL JPA Visitors
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Beryozkin resolved CXF-4221.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.7.0
Jeff, thanks for the patch. I've applied the first part only and we will address the issue of the composite properties in a follow up JIRA. I've decided to avoid adding a second type variable and simply go ahead with the language specific visitors offering the appropriate getters. The 2nd variable does not have a good effect on the rest of API, but I think we may be able to introduce it later if really needed, a bit more visitor implementation experience is needed
> Support FIQL JPA Visitors
> -------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
> Assignee: Sergey Beryozkin
> Fix For: 2.6.2, 2.7.0
>
> Attachments: FiqlParser.java
>
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248627#comment-13248627 ]
Sergey Beryozkin commented on CXF-4221:
---------------------------------------
OK. Can you provide the code you did for populating CriteriaQuery ?
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Szu-Yu Wang (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245794#comment-13245794 ]
Szu-Yu Wang commented on CXF-4221:
----------------------------------
Basically, what I want to do is to use the FIQL parser, but I want to create a JPA criteria query, as opposed to a SQL query. I was using the code template in the advanced features section to accomplish this.
Upon further review, it looks like I'll also have to modify the parser, as the current parser will not be able to do bean.sub-bean.property=gt=5 (which make sense for a SQL implementation) but for a JPA expression level implementation, I can do more than a single-resource query.
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Reporter: Szu-Yu Wang
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246133#comment-13246133 ]
Sergey Beryozkin commented on CXF-4221:
---------------------------------------
> Basically, what I want to do is to use the FIQL parser, but I want to create a JPA criteria query, as opposed to a SQL query. I was using the code template in the advanced features section to accomplish this.
OK. I wonder if the following would work for you:
{code:java}
SearchCondition<CriteriaQuery> search = SearchContext.getSearchCondition(CriteriaQuery.class);
CriteriaQuery query = search.getCondition();
//pass it to JPA
{code}
Try that please.
> Upon further review, it looks like I'll also have to modify the parser, as the current parser will not be able to do bean.sub-bean.property=gt=5 (which make sense for a SQL implementation) but for a JPA expression level implementation, I can do more than a single-resource query.
Indeed, expressions like "bean.sub-bean.property=gt=5" are not supported yet. InjectionUtils has the code for populating a given bean instance based on expressions like 'bean.sub-bean.property'. If you can somehow reuse that and provide a patch then it would be good.
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Reporter: Szu-Yu Wang
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4221) FIQL visitor to return a generic
instead of String
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248181#comment-13248181 ]
Sergey Beryozkin commented on CXF-4221:
---------------------------------------
Hi, I'd like to resolve the issue as Won't Fix or Not a Problem, given that the way to obtain the typed representations of FIQL expressions does already exist, as shown in my previous comment. The only action will be to update the wiki documentation with the clarifications.
I'm OK with having a new JIRA opened for addressing the parsing of 'a.b.c' properties, that can be a good enhancement.
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Szu-Yu Wang
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CXF-4221) FIQL visitor to return a
generic instead of String
Posted by "Sergey Beryozkin (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245120#comment-13245120 ]
Sergey Beryozkin edited comment on CXF-4221 at 4/3/12 10:47 AM:
----------------------------------------------------------------
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
Usually the users would do SearchContext.getSearchCondition(MyClass.class) and then use the resulting search condition to select the matching MyClass instances.
The goal of SearchConditionVisitor is to accumulate a language specific (SQL, etc) representation of the FIQL query which can be fed directly to the external db/storage systems.
what introducing K to SearchConditionVisitor<T, K> will help with ? Can you explain please and prototype some example code ?
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
Possibly not the best name, nonetheless consider it the result of the SearchConditionVisitor visiting individual SearchConsitions and transforming them all into a language specific predicate/filter
was (Author: sergey_beryozkin):
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
Usually the users would do SearchContext.getSearchCondition(MyClass.class) and then use the resulting search condition to select the matching MyClass instances.
The goal of SearchConditionVisitor is to accumulate a language specific (SQL, etc) representation of the FIQL query which can be fed directly to the external db/storage systems.
what introducing K to SearchConditionVisitor<T, K> help with ? Can you explain please and prototype some example code ?
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
Possibly not the best name, nonetheless consider it the result of the SearchConditionVisitor visiting individual SearchConsitions and transforming them all into a language specific predicate/filter
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
> Key: CXF-4221
> URL: https://issues.apache.org/jira/browse/CXF-4221
> Project: CXF
> Issue Type: Improvement
> Reporter: Szu-Yu Wang
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type of the getResult() call. This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like "getPredicate" or "getFilter"...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira