Re: Automatic indexing solution
Re: Automatic indexing solution
- Subject: Re: Automatic indexing solution
- From: Florijan Stamenkovic <email@hidden>
- Date: Tue, 19 Jul 2005 17:09:09 +0200
Just make another entity/table like EO_PK_TABLE named for example
"SERIAL_NUMBER" and each row in the table maintains the last used
serial number for a certain type. One row could be for "invoice"
serial numbers, another for "booking" numbers, etc.
Then use SQL in a synchronized static method to grab the next serial
number using optimistic style locking just as EOF does when generating
primary keys. To see this in action, log out the SQL and watch the SQL
that grabs PK's from the EO_PK_TABLE when saving new entities.
The SQL steps are
1) SELECT the row in the SERIAL_NUMBER table where serial_type equals
"booking"
2) Increment the serial number
3) TRY to update the "booking" row WHERE the serial number equals the
OLD number and the serial_type equals "booking" (this is like an
optimistic locking update which only succeeds if no other app has
updated in the meantime.
4) If the update fails repeat steps 1 to 3 up to N max retries until
you successfully get a new number.
HTH, Kieran
Thank you Kieran,
I think this might be the thing to do. Although I don't really
understand step three (but I have no knowledge of SQL actually besides
the basic functionality and purpose. But I think I can get around it by
logging SQL done by EOF.
But what do you think about the idea of having a
public static boolean isSaving; //before saving new records check it,
if true, wait
variable in Application and allowing saving records only one set at the
time and just before saving the set fetching the last record, updating
all other records (EO level) and then saving and unlocking the app? Is
it harming any WO/EOF concept or something? And would it really work
across instances?
Please note that performance is NOT really an issue. Or better to say
scalability is not. There are not many users for this app as it is only
our internal book keeping. Still, simultaneous access is of course
possible.
Flor
_______________________________________________
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