Regardless of transaction thing, HiLo assignes Id BEFORE it is sent to database. No select is executed.
If lo value is >maxLoValue then a new Hi is obtained but in another transaction. It is the thing that you last said, when exhaust a new Hi value is obtained, Lo values are incremented everytime an object is persisted. Tuna Toksöz Eternal sunshine of the open source mind. http://devlicio.us/blogs/tuna_toksoz http://tunatoksoz.com http://twitter.com/tehlike On Thu, Mar 26, 2009 at 10:37 AM, Peter Morris <[email protected]> wrote: > > > and as for the people asking about what the behaviour was - the simplest > > thing is to setup a quick two-entity domain with hilo id, new one > instance > > of each, session.Save them both and peek into the generated data. > > As I am still at theory level and can't yet do that may I ask a question? > :-) > > If I am about to save 50 new instances does it do something like > > <Separate transaction> > select nextnumber from myidtable; > update myidtable set nextnumber = nextnumber + 50; > </Separate transaction> > > Then assign nextnumber+X to each object about to be inserted? This is how > I > would guess it works, but the name Hi/Lo generator reminds me of an old > strategy in which the user is allocated a range when the app starts and > when > they exhaust the range they request a new one, but it doesn't seem to me > that it works that way so the name confuses me slightly :-) > > > Pete > ==== > http://mrpmorris.blogspot.com > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
