Would you like me to create a task that we mark the API and
documentation mentions of it as deprecated?
Yeah - IMO now is a good time to mark it as deprecated.
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.
What we can do to improve the usability of the data rows is to
produce "unmanaged" objects of a specific class from tabular data
(IIRC JPA spec SqlResultSetMapping should help us with that). For now
you can use data rows in your app, or wrap them in some unmapped user
defined classes to add behavior.
A few side notes:
* "data rows" are billed as a performance optimization feature in the
User Guide, but more importantly, this is a representation of tabular
data. We may need to make it more clear in the docs.
* The EOF example (which IIRC you can map in Cayenne already), is
only addressing an edge case of derived data that doesn't change the
identity of the row, so I don't think you can do a relationship count
as a EOF derived column.
Andrus
On Feb 20, 2007, at 2:21 PM, Aristedes Maniatis wrote:
On 20/02/2007, at 1:43 AM, Andrus Adamchik wrote:
I think Andrus is the right person to answer your question, but I do
recall a conversation where the intention was for derived dbentities
to be removed.
True - that was an ugly and limited workaround. We do need to get
rid of it.
Would you like me to create a task that we mark the API and
documentation mentions of it as deprecated? Would a goal be to
replace this with something like:
http://developer.apple.com/documentation/LegacyTechnologies/
WebObjects/WebObjects_4.5/System/Documentation/Developer/
EnterpriseObjects/EOTools/DerivedProperties1.html
or do you think that SQLtemplates are the catch all for this?
SQLTemplate can also work with data objects, just need to make sure
the object properties match the returned column names. The SQL
template has a nice facility to support multiple database
versions as
well.
Yep, that would be my recommendation as well.
I've read the docs but I don't quite understand how this mapping
back to an object entity will work. If I use the #result notation
to specify all the attributes already in the _Artist.class and I
then add something like paintingCount to Artist.class, how do I
then tell the SQLtemplate to return that derived attribute into
paintingCount?
#result('COUNT(SELECT ...)' 'int' paintingCount)
Will that do it? Is the columnAlias mapped to the attribute in the
object entity?
Ari
-------------------------->
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
