[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050748#comment-14050748
]
Adam Heath commented on OFBIZ-4053:
-----------------------------------
I don't see it. ModelViewEntity.populateReverseLinks() walks all <view-link>,
but does nothing with any <entity-condition> that was defined. It only deals
with <key-map>.
A condition can reference a lhs or rhs field that is not mentioned in a key
map, nor in the available field aliases. This means it would be hidden from
the conversion code, so an update of a member entity row would not clear the
view cache.
> 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)
