| 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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/lists% 40anderhome.com
This email sent to [EMAIL PROTECTED]
--
__________________________________
Rico Landefeld
Takwa GmbH
Softwareentwickler
Bodelschwinghstr. 25
99096 Erfurt
Tel.: +49 361 6534096
Fax.: +49 361 6534097
eMail: [EMAIL PROTECTED]
WWW: http://www.takwa.de
__________________________________
|
