Hi Gustavo, This is one of those situations where the business rules contradict Normalization rules for the DB.
The Business rules override the normalization rules. Invoice should have it's own relationship to Address, and it should not point to the same object as the person does. When you create an invoce and give it an address, you should duplicate the person's address object and then add the duplicate to the Invoce. You will end up with multiple copies of the same address in the DB, but if the Invoice must maintain the address without changes, you can't relate it to the same object. Duplicating EOs is simple using the method outlined in Practical WO, and I think the copyable interface described there has been added to ERXGenericRecord so you should be able to do this with very little work. Having multiple instances of the same object is usually a no-no from both the WO and DB perspective, but in the situation you describe, duplicate instances _is_ the way to go, because they are only duplicates by coincidence, not by business rule. Dave On Nov 16, 2009, at 6:22 AM, Gustavo Pizano wrote: > Hello all. > > I know this is off topic, but you guys have helped me in the past with such a > questions, so I hope Im not bothering anybody. > > Im building a Invoicing app, so I have my EOModel and this is what I have. > > Person: > Client: Parent is Person > User: Parent is Person. > > Person < >> Address (toAddress) > > Invoice << > User (toUser) > Invoice<< > Client (toClient) > InvoiceItem<< >> Invoice > InvoiceStatus< >> Invoice > > now... what happens if the Person changes address?, it will change the > address of all already created invoices, which for record purposes its not > allowed, it think. (I mean my already created invoices should stay as they > where created) > > So is it correct to add a relation from Invoice << > Address ?, so when I add > a new address to Person the invoice will kept the old address. right? > > how can I avoid when modifying the address, if I do this, then the invoice > toAddress will change also. > > Thanks > > > G. _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com > > This email sent to webobje...@avendasora.com > > David Avendasora Senior Software Engineer K12, Inc. ***** WebObjects Documentation Wiki : http://wiki.objectstyle.org/confluence/display/WO/ ***** WebObjects API: http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html ***** _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
