[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050636#comment-14050636
]
Adam Heath commented on OFBIZ-4053:
-----------------------------------
You don't want a find()/findList() call to cache when you are going to update
the value, so how do you suppose we would implement that?
And, if cache is not an option, how do you see the annotated calls being cached?
Plus, there are currently issues with view caching; These are the things I know
don't work:
* <entity-conditon> on a view
* <entity-condition> on a view-link
* nested views, to any depth(it's close, but broken by the above 2 items)
* complex alias
* not certain about function/group-by
Here's a rough example of a complex view:
{code}
ContactMechView
member:ContactMech
optional-member:TelecomNumber
optional-member:PostalAddress
PartyView:
member: Party
optional-member:Person
optional-member:PartyGroup
PartyContactMechView:
member:ContactMechView
member:PartyContactMech
optional-member:PartyContactMechPurpose
ProfileView:
member:PartyView
optional-member:PartyAttribute
condition: attrName: 'BF_TOKEN'
optional-member:PartyContactMechView
condition: contactMechPurposeTypeId: 'PRIMARY_EMAIL'
optional-member:PartyContactMechView
condition: contactMechPurposeTypeId: 'HOME_PHONE'
OrderView:
member:OrderHeader
member:OrderItems
ProfileAndOrderView:
member:ProfileView
member:OrderView
{code}
> 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 was sent by Atlassian JIRA
(v6.2#6252)
