On 05/06/2007, at 12:06 AM, Michael Gentry wrote:
Putting it in DataObjectUtils doesn't seem the right place to me.
Using your example:
DataObjectUtils.objectForQuery(...)
returns a DataObject (which makes sense to me, being packaged in
DataObjectUtils). Something that returns an int, which can't even be
converted into a DataObject, doesn't feel like it should be in
DataObjectUtils.
Just putting in a couple of cents here :-) but the name
DataObjectUtils doesn't have to imply that it returns objects of type
DataObject but operates on DataObjects (which means it could either
run a query against or indeed return object(s) of that type).
After all, there is already operations here that return integral
types: e.g.,
intPKForObject(Persistent dataObject)
I liked Lachlan mentioning @avg/etc, too. I had mostly forgotten
about those operations in EOF. I'm not intending to side-track the
count topic, but I also think we need the ability to handle something
like employee.readNestedProperty("manager.employees.fullName") which
EOF can handle (you'd get a list of strings).
Yep, or manager.readNestedProperty("[EMAIL PROTECTED]") which would
resolve to perform a query like the following (by finding the
destination entity of relation employees [1]):
Expression qualifier = ExpressionFactory.matchExp("manager", manager);
StatsQuery query = new StatsQuery.Avg(Employee.class, qualifier,
"wage");
return DataObjectUtils.intValueForQuery(context, query);
with regards,
--
Lachlan Deck
[1] Note: that'll get trickier with inheritance
