Jeffrey Pearson wrote on 4/4/06 1:58 PM:
After viewing the video, it looks like I am going to be much happier if I copy off the tables, use EOModeler to actually create the tables in the db and then import the data. It looks like some invisible plumbing is set up by using EOModeler to generate the database tables.
As David and Paul have pointed out, you probably don't need to use EOModeler to recreate your database tables. One hiccup they didn't mention is that EOF is unaware of DB constraints. This can be a major issue when dealing with legacy DBs and it will cause major headaches when you are persisting complex EOs that have a bunch of relations.
For example, say you have the relationship File -->> Attribute and you create a new File with a bunch of Attribute relations. EOF tends to process things in order alphabetically, meaning it first runs statements to insert the Attributes, and then to insert the File. If you have a foreign key constraint on Attribute that references the File PK, your DB will throw an error at this point.
Some DBs will let you temporarily disable constraints, thus avoiding this error. This has not worked for me with MySQL 4.1.x. (It solved one problem but introduced others, and that's a topic for another thread.)
Many WO folks will tell you that you don't need DB constraints as long as your EOModel is correctly constrained. This is true, but it doesn't address the situation of dealing with a legacy DB which you don't control the constraints on. At this point, the conversation usually descends into a flamewar, so I'll leave it there.
Good luck, zak. _______________________________________________ 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]
