cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@ish.com.au>
Subject Re: entities with calculated fields
Date Tue, 20 Feb 2007 14:33:23 GMT

On 20/02/2007, at 10:49 PM, Andrus Adamchik wrote:

> As to the replacement, this is not a simple question and it goes to  
> the ORM basics, namely - only straight table rows joined via PK/FK  
> keys can be mapped to an object graph in a clean fashion. If a  
> result row's identity is unclear (e.g. a few table rows aggregated  
> in some derived data rows), ORM model breaks. In Cayenne we  
> recognize that by separating *objects* managed by Cayenne runtime,  
> and *data rows* representing some tabular data that may or may not  
> have a direct relationship to an object with a given identity. Data  
> rows can be fetched, but they are unmanaged.

Moving to dev...

Derived attributes don't need to break the object graph. They would  
be read only since it makes no sense to write that data back to the  
database, but they could cleanly map SQL query results to an object  
entity attribute. Mostly I'm thinking of aggregate functions across a  
relation (SUM, COUNT, MAX, etc) but anything would be possible  
including a flattened attribute (where a field from a related table  
is added to the many table attributes - this might be easier to deal  
with in some situations) or more exotic SQL functions like CHECKSUM  
or SOUNDEX.

Sometimes it might be necessary to use in-database functions rather  
than adding this in Java to the object entity sub-class. In my case,  
mainly for speed, but I can imagine other uses too.


Derived entities are another situation again. They need to be  
completely read-only since you can never map them back to database  
rows. But as you say, data rows are a good solution to this and the  
SQLtemplate mechanism is very flexible. To be honest I don't quite  
understand the need for derived entities with grouping (is this for  
report writing?) but should they stay if they promised to be read- 
only? My interest in them was because I thought they were a way to  
create derived attributes.


I'm still not clear about the SQLtemplate. Is it the columnAlias  
which defines how an attribute is mapped to the object entity? How  
does this work today if we want objects back out and not just data rows?

Ari Maniatis



-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A



Mime
View raw message