For reference: http://lists.apple.com/archives/webobjects-dev/2008/Feb/msg00478.html
On Dec 22, 2010, at 2:14 PM, David Avendasora wrote: > > On Dec 22, 2010, at 1:51 PM, Jesse Tayler wrote: > >> whoa! unexpected can-o-worms! >> >> I guess I had been using FrontBase...But now I'm on mysql via amazon RDS >> which really seems like a nice service. >> >> I really could care less about how keys are constrained really, I have a new >> WO-centric data model and WO is the main handler of the data and this is a >> new setup, so the path of greatest WO'ness is the clear choice. >> >>> 1. The FK and the ID it's pointing to are the same field types. >> >> well, they really do all seem to be properly inheriting from ID prototype >> and aside from being marked as non-required and I guess I turned off locking >> for that property...the ER tables are getting created from scratch at the >> same time etc. >> >>> 2. (Most likely) the table must be InnoDB, not MyISAM. MyISAM does not >>> support FK constraints. >> >> the tables do seem to be inoDB (whatever that is) and utf-8 in the hope of >> capturing various languages properly. >> >> I wonder this - I have at least one table that I was using that is a >> correlation table (invitation) and the eogen makes key constraints for that >> table -- the trouble comes for me when I connect to the ERAttachemnt model. >> >> NOW -- I did have some trouble with that relationship while getting started, >> I know I had to delete a framework I had somehow imported and changed in >> order to get it in sync with the deployment model which I bundle up with the >> app. (I'm also new to eclipse) >> >> I really thought I had a model confusion going on...something stemming from >> that duplicate model or something. >> >> Also note -- I have been able to upload photos while I've been dropping and >> recreating tables and model files and testing things. >> >> If I recall, I opted out of the egoen'd key constraint and some point and >> was able to store attachments without the error message at runtime - but it >> has been inconsistent and of course, if I could recall the recipe and it >> worked, I'd just stick with it. >> >> Thoughts? > > EOF doesn't do DB operations in a predictable/consistent/deterministic way. > If it worked before in MySQL with FK constraints in the DB, then it was just > luck. EOF could easily just have inserted things in the right order by > complete chance. I used MSSQL Server on a previous project and it took a > while for me to figure out why sometimes the same transaction would fail and > other times it would run just fine. If you have non-deferrable FK constraints > in the DB you must either force EOF to do things in the right order, or > remove the constraints. > > There is code that Chuck wrote (that others have eluded to) that will put 99% > of normal DB operations in the correct order. Use it. Don't look back. > >> Should I opt away from constraints anyway? Model setting I should try? > > NO! Use constraints. Use them. USE THEM! You say that WO is the main handler > of the data, but sooner or later something else is going to touch the data > (could be another app, could be you running SQL commands from the console) > and the database will allow you to happily have FKs that point to nothing, > which EOF will also choke on (although there's a way to force it to swallow > it using Wonder). > > Use the Entity Ordering code of Chuck's. I believe you just add a line of > code to the Application constructor to use an Entity Ordering Delegate (not > sure, it's been a while, google is your friend). And only remove the FK > constraints on self-referential relationships. > > Dave > > > _______________________________________________ > 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 > > _______________________________________________ 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
