On Feb 09, 2009, at 20:59, getsharp wrote:
> I only use derived attributes to represent a concatenation of
> several columns as a single attribute, eg fullName =
> CONCAT(first_name,' ',last_name)
>
> It's helpful for building qualifiers, eg fullName = 'Joe Citizen'
>
> Two things bug me though:
>
> * non standards compliant databases leaving me with database
> specific syntax in my model (I'm looking at you MySQL as per my
> example)
> * displaying derived attributes where an EO is not a result of a
> database fetch, eg newly inserted EOs
>
> It's probably less pain to just add methods to my Entity classes for
> a) returning concatenated attribute values and b) returning
> qualifiers in cases where I want to keep the clutter of building
> them out of components.
>
> The small win of having ease of qualification results in 2 things
> that bug me!
>
> Any thoughts on this?
Well, not really answering your question, I'd just like to say that
this is in my opinion not the best way to go about this. Derived
properties have some caching issues. Here's a quote from Apple's docs
on this:
"One of the most important benefits is the internal update
notifications that enterprise objects send
and receive. In the previous example, if you change an employee’s
monthly salary, the derived
attribute that calculates the annual salary is then incorrect. And
since the attribute is derived, its value
as it exists in the enterprise object is immutable. Unless the object
is flushed from the access layer’s
snapshot and refreshed, the derived attribute is stale and inaccurate. "
For this I only ever define derived attributes in Java. Which
incidentally also enables you to skip dealing with vendor specific SQL.
As for your qualifier, it is easily redefined as
firstName.equals("Joe") && lastName.equals("CItizen") or the
EOQualifier / SQL equivalent of that.
Two cents,
F
This archive was generated by hypermail 2.0.0 : Tue Feb 10 2009 - 09:30:34 EST