Re: Models confused?
Re: Models confused?
- Subject: Re: Models confused?
- From: David Avendasora <email@hidden>
- Date: Wed, 22 Dec 2010 14:14:39 -0500
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden