Keep it simple use UUID. Pierre -- Pierre Frisch [EMAIL PROTECTED]
On Jan 23, 2008, at 11:19, Mike Schrag wrote:
On failed save EOF does not update the global IDs with integer PKs. Do something trivial like adding a null-allowed column in EO but making nulls not allowed in the DB. Attempt to save. When it fails change the DB to allow nulls or fill in the property that cannot be null. Save again. You'll notice that the PKs grabbed for the first attempt are skipped and that EOF will ask for PKs again and will use those.You might be able to wrap your saveChanges in a loop until it succeeds, but you'd need to intercept and parse the duplicate primary key exception, which would be db-specific. What I don't know is if you have deferred constraints if that also includes PK conflicts, and if so, would you only get a single exception on save and not know which item it actually correlated with (or even that it was a dupe PK error -- every db sends this back in different ways, and some don't even support codes on these, so you literally have to parse the exception messages, which is a disaster in the making). Definitely a lot of unfun things you would likely have to do to try and get this to work, which is why I think the better solution is to fix pk generation period and support autoincrement columns in the first place (so you wouldn't even have to deal with this). Not to say that's a trivial change by any means, but EOF really should be capable of using them. That eo_pk_table thing always felt like a huge hack to me.There's already an example of some auto-PK fixes in the PostgresqlPlugin. Should the sequence object not exist, the plugin will recreate it. Furthermore, should it exist but be returning IDs that are too low then assuming you catch adaptor exceptions you can try saving again and eventually you'll bump the sequence high enough. You can also stop after the first save, regenerate primary key support, then save again and it will pull new PKs.This is different, though ... This is a failure in the pk generator, which is pretty straightforward to catch and handle in the plugin. The problem you're talking about is a failure during commit, after the plugin's pk generator has already run.So clearly it's not impossible to add some code that upon primary key conflicts will simply regenerate the PK support. One drawback is that while you are regenerating the PK support you really ought to block all other access to the database or else you could easily get two DB clients trying to do the regeneration concurrently.Nothing's _impossible_ :), but I suspect it is pretty tricky to get it to work right. You basically have all the same context the framework does at this point, though. I suspect you could try to prototype this in your own code at a higher level to see if there's even enough info available to pull it off.ms _______________________________________________ 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/pierre%40apple.com This email sent to [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
