Re: Flattening attributes

Wed, 15 Feb 2006 14:29:19 -0800

Excerpt  from EOModel User's Guide:

When Should You Flatten Attributes?

Flattening attributes is just another way to conceptually “add” an attribute from one entity to another. A generally better approach is to traverse the object graph directly through relationships. Enterprise Objects makes this easy by supporting the notion of key paths.

The difference between flattening attributes and traversing the object graph (either programmatically or by using key paths) is that the values of flattened attributes are tied to the database rather than the object graph. If an enterprise object in the object graph changes, a flattened attribute can quickly get out of sync.

For example, suppose you flatten a departmentName attribute into an Employee object. If a user then changes an employee’s department reference to a different department or changes the name of the department itself, the flattened attribute won’t reflect the change until the changes in the object graph are committed to the database and the data is refetched (this is because flattened attributes are derived attributes—see “Definition (Derived Attributes)” for more details). However, if you’re using key paths in this scenario, users see changes to data as soon as they happen in the object graph. This ensures that your application’s view of the data remains internally consistent.

Therefore, you should use flattened attributes only in the following cases:

  • If you want to combine multiple tables joined by a one-to-one relationship to form a logical unit. For example, you might have employee data that’s spread across multiple tables such as ADDRESS, BENEFITS, and so on. If you have no need to access these tables individually (that is, if you’d never need to create an Address object since the address data is always subsumed in the Employee object), then it makes sense to flatten attributes from those entities into the Employee entity.
  • If your application is read-only.
  • If you’re using vertical inheritance mapping. See “Vertical Mapping”.

On Feb 15, 2006, at 11:36 AM, Ken Anderson wrote:

Rico,

Can you tell us a little bit about why you want to have all these flattened attributes?  I religiously avoid them.  Since you can use keypaths with KeyValueCoding, I don't often see a use for flattened attributes.

In the relationship from company to address, do you have 'Propagate Primary Key' checked?

What type of attribute is the primary key of Address?  Is it a class property?

Do you have the address relationship marked as Mandatory?  If you do, EOF will create the relationship and target entity for you, so you should be sure not to replace it (otherwise, you'll have an orphaned EO in the context).

Ken

On Feb 15, 2006, at 6:11 AM, Rico Landefeld wrote:

hi all,

i have the following problem with flattening. i have an address entity in
my eomodel wich is used by many other entities like company. company has a
to-one relationship to address. i like to flatten some of the address
attributes into company (address is a weak entitytype). if i insert an
company without filling the address fields there is no insert into the
address table. when some address fields are filled, eof generates an
insert for address but without an primary key and the address relationship
of the company object is empty! i have written an big
EODatabaseContext.Delegate to handle this. is there a better solution?

thank you for your answers!

rico

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:

This email sent to [EMAIL PROTECTED]

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:

This email sent to [EMAIL PROTECTED]

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to