Yep, still need to override the derived attribute's getter and mimic/duplicate
the concatenation (in this case) to ensure it reflects the uncommitted changes,
very noticeable when you have a new object that hasn't been saved to the
backing store!
The big gains from this type of attribute become
if there were no bug the only difference would be that eogenerator would make
the derived column 'allows null'?
should I add a Jira?
Ted
--- On Wed, 11/24/10, Mike Schrag wrote:
> From: Mike Schrag
> Subject: Re: EOModel and derived column.
> To: "Theodore Petrosk
A note about those columns, they are only evaluated during fetch since their
content is generated in the SQL. So if your user updates their last name, the
full name won't update until the changes are committed and then fetched again.
Just a head's up.
John
Sent from my iPhone
On Nov 24, 20
that's just an eogenerator template bug ...
ms
On Nov 24, 2010, at 2:37 AM, Theodore Petrosky wrote:
> I am reading the Red Webobject 5.0 book and I think I finally understand the
> small section on creating an attribute the is derived.
>
> (I am using postgresql as the backend)
>
> so my Us
I am reading the Red Webobject 5.0 book and I think I finally understand the
small section on creating an attribute the is derived.
(I am using postgresql as the backend)
so my User entity has a firstName and a lastName. I created an attribute called
'theFullName' as derived "firstName || ' '
