• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Flattening attributes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flattening attributes


  • Subject: Re: Flattening attributes
  • From: Rico Landefeld <email@hidden>
  • Date: Thu, 16 Feb 2006 16:11:26 +0100

hi again,

maybe you're right. but sometimes means not to fight against eof not to use features how they are described in apples documentation. see the description for flattened attributes in eomodeler users guide. in my opinion, flattening is only appropriate implemented for relationships not for attributes. but it would be a nice feature to avoid denormailzation of  database designs. but, how i mentioned earlier, its cosmetic, nice to have but not essential. it seems for me that nobody use this feature really.

rico
Rico,

You're using terms and ideas that don't really fit into the EOF way of doing things.  As many people here have said before, don't fight EOF - it's not worth it.  If you have different requirements for different addresses, why not just put the fields you need in each entity?  If you're writing a lot of code and jumping through a lot of hoops, you're probably not doing things the EOF way.  And I can tell you for sure - what you're trying to do does not fit.

Trust me, your problems are not solved in 5.3.1 - you need to take a different approach.  If you could share some of your constraints that led you to this design, people on the list could certainly help.  >From what you've written so far, my gut feel is you should either make Address a regular entity, create relationships to it, and do validation in the owner, or just move the datafields you need into the owning entities.

Ken

On Feb 16, 2006, at 4:10 AM, Rico Landefeld wrote:

hi ken,

i have need for address related stuff in many entities like foreman, company, building owner and more (the "main" entities). for a clear database design i've introduced an address entity an connected it with to - one relationships with the "main" entities. in er-modeling address is called "weak entitytype". it has no "natural" identity without an relationship to another entity. my problem is that i want to do model driven validation. but there are differences between the "main" entities. in the company some address fields are not mandatory but in other entities they are. so i can't do address validation in the address entity. here is an excerpt from the eomodel users guide for my case (thank you robert):


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.
primary key propagation, "mandatory" and "owns destinations" options doesn't work. primary key propagation work only for m:n connector tables. "mandatory" only generates an validation exception that the address relationship of company can't be empty. "owns destination" means only if i delete an address object from this relationship than eof will delete the address object too. but i work with wo 5.2.4, maybe in 5.3.1 this problem is solved. maybe my problem is more cosmetically. an easy solution ist to store the address stuff in the "main" entities directly. but this is'nt nice database design.

thank you for your answer,
rico
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@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to
email@hidden



--
__________________________________

Rico Landefeld
Takwa GmbH
Softwareentwickler
Bodelschwinghstr. 25
99096 Erfurt
Tel.: +49 361 6534096
Fax.: +49 361 6534097
eMail: email@hidden
WWW: http://www.takwa.de
__________________________________
    


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

This email sent to email@hidden

References: 
 >Flattening attributes (From: "Rico Landefeld" <email@hidden>)
 >Re: Flattening attributes (From: Ken Anderson <email@hidden>)
 >Re: Flattening attributes (From: Ken Anderson <email@hidden>)

  • Prev by Date: Re: Custom Class Problems
  • Next by Date: Practical EditingContext Design Question
  • Previous by thread: Re: Flattening attributes
  • Next by thread: Re: Flattening attributes
  • Index(es):
    • Date
    • Thread