On Feb 20, 2007, at 5:33 PM, Aristedes Maniatis wrote:
>
> 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.
Aggregate functions require GROUP BY (as they all *aggregate* rows;
except for some edge conditions like "select count(*) from x" where
GROUP BY is implied), flattened attributes require joins (that will
be supported at some point as a separate feature). Derived attributes
(in WebObjects sense) cover what's left - normally some kind of
straightforward derivatives of the root table columns (e.g. concat of
first name/last name). I am 99% sure that "no real aggregate"
limitation applies to WO EOF derived attributes (if not, please
correct me).
> 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.
No, GROUP BY is implied in any aggregate query so if you take GROUP
BY out of equation, derived entities become redundant and can be
mapped as regular (read-only) db-entities.
So - single table, multi-table and aggregate entities are all
different beasts in both (a) mapping semantics and (b) runtime
handling. EOF derived columns and Cayenne derived entities are both
hacks (albeit often useful) that allow to present certain cases of
aggregate and non-standard single table query results as simple
single table queries.
> I'm still not clear about the SQLtemplate. Is it the columnAlias
> which defines how an attribute is mapped to the object entity?
Yes. But more like a DbAttribute of that ObjEntity's DbEntity. This
query:
"select 1 as ARTIST_ID, 'A' as ARTIST_NAME, '1900-01-01' as
DATE_OF_BIRTH"
can be converted to the Artist object.
> How does this work today if we want objects back out and not just
> data rows?
Essentially the result set MUST match the columns of DbEntity for the
ObjEntity in question. This is indeed very limiting, and I hope we
will improve it in 3.0 - but likely for unmanaged objects.
We can do two things to replace derived entities:
* Allow read-only ObjEntities without DbEntities.
* Add support for JPA-compatible SqlResultSetMapping.
Andrus
This archive was generated by hypermail 2.0.0 : Wed Feb 21 2007 - 07:17:59 EST