cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lachlan Deck <lachlan.d...@gmail.com>
Subject Re: performing count
Date Tue, 05 Jun 2007 14:04:36 GMT
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("employees.@avg.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


Mime
View raw message