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..vg/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("employees..vg.wage") 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
This archive was generated by hypermail 2.0.0 : Tue Jun 05 2007 - 10:05:19 EDT