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
This archive was generated by hypermail 2.0.0 : Tue Feb 20 2007 - 06:23:10 EST