Re: Re DisplayGroups. Inserting and deleting objs
Re: Re DisplayGroups. Inserting and deleting objs
- Subject: Re: Re DisplayGroups. Inserting and deleting objs
- From: Jevon Hills <email@hidden>
- Date: Wed, 22 Jan 2003 16:44:32 -0700
Thank you so much for your assistance thus far.
Thanks to you I'm finding that my problem is not my code but the
database I'm working with.
I've test out the Join in Many to Many and discovered 2 principle
differences between my 'link' table and the one that eomodeler
generated.
Eomodeler My Pre-existing
had 2 columns both pk 3 columns: the 2 fks and a 3rd as pk
flattened relationships nothing of the sort
I have just adjusted my model to match what eomodeler would generate
and will now attempt to re code my class appropriately.
Thankyou once again.
On Wednesday, January 22, 2003, at 04:18 PM, Art Isbell wrote:
On Wednesday, January 22, 2003, at 12:30 PM, Jevon Hills wrote:
Although eomodeler defined the relationship for me it only gave the
methods
card.addToConsolesmartcardlinktable(obj)
card.removeFromConsolesmartcardlinktable(obj)
console.addToConsolesmartcardlinktable
and
console.removeFromConsolesmartcardlinktable(obj)
These methods would not be defined if your many-to-many relationship
had been created by EOModeler. There would be no mention of the link
entity at all. A pure link entity (i.e., no other attributes other
than its primary keys) is an artifact of a relational DB's
many-to-many relationship. It has no meaning in your app, so it
shouldn't be accessed, no objects of its class created, etc.
How do I define a relationship for the 3 tables to get the methods you
mention so I don't use id's???
For tablenames let's assume console, smartcard, and csl.
In EOModeler with the table mode selected, select the model entry at
the top of the left split view. Then Apple-click the Console and
SmartCard entries in the right split view. Click the Property>Join in
Many-to-Many menu item. Voila! EOModeler just modeled a many-to-many
relationship for you. Ignore the link entity it created. Don't set a
custom EO class or generate Java code for it. But you will need a DB
table for it, so generate the SQL for that, if necessary. Replace the
Java code that you have already generated for the Console and
SmartCard entities or carefully merge the existing code if you have
made modifications. But don't include methods for relationships that
aren't class properties.
Try to stop thinking in terms of "table", "column", "primary key",
and "foreign key" which are relational DB objects. Instead, think of
"entity", "attribute", and "relationship" which are object DB objects.
EOF is an object-to-relational mapping technology. You must deal
with the object side. EOF will handle the relational side. If you
try to handle the relational side in your code, you'll be battling EOF
for control, and EOF usually wins :-)
Art
http://homepage.mac.com/aisbell/
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
Jevon K. Hills
Intern - Zymeta Media Promotion Systems
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.