• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Automatic indexing solution
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Automatic indexing solution (From: Florijan Stamenkovic <email@hidden>)
 >Re: Automatic indexing solution (From: Florijan Stamenkovic <email@hidden>)
 >Re: Automatic indexing solution (From: Kieran Kelleher <email@hidden>)

  • Prev by Date: Re: Webobjects-dev Digest, Vol 2, Issue 411
  • Next by Date: D2JC Login Example
  • Previous by thread: Re: Automatic indexing solution
  • Next by thread: Re: Webobjects-dev Digest, Vol 2, Issue 411
  • Index(es):
    • Date
    • Thread