[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971033#action_12971033
]
David E. Jones commented on OFBIZ-4053:
---------------------------------------
First off, I like this general direction. A while back (years ago) when
thinking about cleaning up the delegator API it seems like we discussed the
idea of using a query object with various methods instead of the find* methods
with their large numbers of parameters, that are individually sometimes complex
anyway. Scott's idea earlier this summer was an extension of that where the
various methods instead of returning void would return the query object to
allow chaining (definitely tightens up the code).
Anyway, in the Moqui framework here is what I've done with those ideas, for
those interested. Here is the EntityFind interface (for the query object):
http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/framework/src-api/org/moqui/entity/EntityFind.java?revision=25&content-type=text/plain
This is called from the find method on the EntityFacade interface (the
equivalent of the delegator in Moqui), and there are no other find methods:
http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/framework/src-api/org/moqui/entity/EntityFind.java?revision=25&content-type=text/plain
With this EntityFind interface the idea is that you are setting up the details
of the query, and you could potentially run more than query with the same
object. You'll also notice that Moqui includes a EntityList interface in
addition to the EntityListIterator concept instead of returning a generic
List<EntityValue>, and that might be something useful in OFBiz too (mostly to
have convenience methods right there instead of using EntityUtil).
I actually started with the EntityFindOptions class and then expanded it based
on the various parameter and return value options for the delegator find
methods. The result has a LOT less redundancy, and the code should be more
readable (and more similar to the XML "code" where markup describes everything
instead of having to know which parameter means what).
Another detail: should the query object be immutable? I decided that it should
not be in Moqui, and the various methods on EntityFind that return an
EntityFind just return a this reference as it is ONLY for convenience and
having an immutable object would result in all sorts of unused query objects
being created.
Anyway, there are some thoughts, for what it's worth...
It would also be nice if the ShoppingCart and ShoppingCartItem worked in a
similar way... ;)
> Implement an Entity Query Builder
> ---------------------------------
>
> Key: OFBIZ-4053
> URL: https://issues.apache.org/jira/browse/OFBIZ-4053
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
> Affects Versions: SVN trunk
> Reporter: Scott Gray
> Assignee: Scott Gray
> Attachments: builder.patch
>
>
> As discussed on the dev list here:
> http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
> Attached is an initial implementation of builder classes (of sorts) that make
> use of method chaining in order to simplify use of the Delegator interface to
> query entities.
> Rather than taking all possible query parameters into a single method as the
> delegator does, this implementation instead builds a query through a
> succession of distinct method calls.
> A simple example:
> {code}
> // Using the Delegator interface directly
> eli = delegator.find("FinAccountTrans", condition, null, null,
> UtilMisc.toList("-transactionDate"), null);
> // Using the new implementation
> eli =
> EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator();
> {code}
> A more complex example:
> {code}
> // Delegator
> EntityCondition queryConditionsList =
> EntityCondition.makeCondition(allConditions, EntityOperator.AND);
> EntityFindOptions options = new EntityFindOptions(true,
> EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
> EntityFindOptions.CONCUR_READ_ONLY, true);
> options.setMaxRows(viewSize * (viewIndex + 1));
> EntityListIterator iterator = delegator.find("OrderHeader",
> queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options);
> // becomes
> EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
>
> .from("OrderHeader")
>
> .where(allConditions)
>
> .orderBy("orderDate DESC")
>
> .maxRows(viewSize * (viewIndex + 1))
>
> .cursorScrollInsensitive()
> .iterator();
> {code}
> A couple of issues with the implementation so far that I'm not entirely happy
> with:
> - I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
> something like EntityList.use(delegator). The latter requires less typing
> and I think is more intuitive than typing EntityBuilderUtil because of its
> similarities to the corresponding minilang method calls, I actually kept
> having trouble remembering what it was called when converting some delegator
> calls over. It also requires a little more typing (16-17 characters vs.
> 12-13), not a big deal but every little bit helps with what would be a very
> commonly used class.
> - I'm struggling to see the point of having the GenericQueryBuilder
> interface, the two classes share very little in the way of API and its use
> seems a little superfluous to me.
> Opinions on the above points or anything else to do with the implementation
> are most welcome. I'd like to get the API locked down (and hopefully some
> javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
