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: David Elliott <email@hidden>
- Date: Wed, 23 Jan 2008 13:53:10 -0500
On Jan 23, 2008, at 9:25 AM, Mike Schrag wrote:
Why does EOF throw an exception ? Why doesn't it just say, "hey,
somethings not write here, i'll do a MAX() and sort myself out" ?
Probably the reason is that it generates the PK first from your
eo_pk_table, then writes the EO to the database much later in the
process. The writing of the EO to the database is the part that
fails, at which point it's already switched out your EO's temp
global id for a real global id. It would be a likely very nasty
architectural change to get that to behave the way you want,
because it would have to essentially change your EO's global ID.
Assuming that is the case, I think you should make the more
generally useful request "support autoincrement pk columns and end
this eo_pk_table silliness". It would ALSO take a substantial
architectural change, but it puts you in a much better position at
the end of it.
Huh?
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.
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.
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.
-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