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: Chuck Hill <email@hidden>
- Date: Wed, 23 Jan 2008 11:43:14 -0800
On Jan 23, 2008, at 11:19 AM, 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.
Difficult, but not impossible.
What I don't know is if you have deferred constraints if that
also includes PK conflicts,
I am pretty sure that it does.
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).
You can drill down into the SQLException and extract the standard
error codes. I have only done this for FrontBase and MS SQL so other
databases may not provide this. This really needs support in the
JDBCPlugin for each database.
With deferred constraints you could only get to a table name, not the
specific EO. And even the table name is DB specific. That should be
enough to fix a PK problem though.
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.
I am not sure how the auto-increment column thing could be made to
work (nor I am sure that it can't). If it could, that would be a far
better solution. It would also be very valuable in cases where WO
and non-WO apps write to a database. Most other applications would
expect to be using an auto increment column. As it is, mixing these
on the same database is a real challenge.
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.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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