Re: Why doesn't EOF sort our PK problems itself ?
Re: Why doesn't EOF sort our PK problems itself ?
- Subject: Re: Why doesn't EOF sort our PK problems itself ?
- From: Mike Schrag <email@hidden>
- Date: Wed, 23 Jan 2008 14:19:29 -0500
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden