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: "Mr. Pierre Frisch" <email@hidden>
- Date: Wed, 23 Jan 2008 11:28:47 -0800
Keep it simple use UUID.
Pierre
--
Pierre Frisch
email@hidden
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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