2010/8/20 Michał Cukierman <mcukier...@partbook.eu>
>
> There should be a method for doing sth like:
> EntityCondition.makeCondition("shipmentId", EntityOperator.IN,
> CustomWhereCondition).
> There should be extended methods for making joins.
> As long as those do not exist - we should at least try use P
>
"IN" (and "NOT IN") conditions should be definable on view entities. The
XSD defines an "IN" operator for entity-conditions and implies that
entity-conditions are valid in view entities, but I couldn't get this to
work. I can't tell how you would represent the right hand side of "IN",
either. There is a TODO comment in the XSD for "NOT IN".
I'm sure the implementation of this becomes rather complicated for all the
different SQL flavors that OFBiz supports, especially when you take it to
the next level, "SELECT" on the right hand side of "IN".
Opentaps has a "Query Tool" to deal with situations where implementing a
query concept is beyond what the entity delegator will do,
in order to support things like JDBC PreparedStatements, "IN" clauses and
subselects.
http://www.opentaps.org/docs/index.php/Using_the_Query_Tool
Notice that this approach was abandoned in favor of Hibernate integration.
With that, I would personally just punt in this situation, get a connection
from the delegator, and deal with the results as a Map. Before I did that,
I'd want to make sure that my assumptions are correct (performance of
subsequent cached queries, cost of traversing an EntityListIterator for
conditions, selecting on a view or DVE, etc.)
--
James McGill
Phoenix AZ
