Aaaaaaah! re-read your first post. Nice/useful/safe idea. If you will implement it, and you want share it, I'll be happy to add it in NHibernate as one of the available "standard" generators.
On Wed, Feb 2, 2011 at 7:50 PM, Oskar Berggren <[email protected]>wrote: > No I used the OP's choice of word for what he described. Not sure > that's a good name though. Perhaps a better name could be > "RangeAllocating" generator. > > /Oskar > > > 2011/2/2 Fabio Maulo <[email protected]>: > > for MaxId do you mean > > "select max(id) from table" ? > > > > On Wed, Feb 2, 2011 at 7:41 PM, Oskar Berggren <[email protected] > > > > wrote: > >> > >> In other words, implementing such a "MaxId"-based generator should be > >> perfectly doable, but it wouldn't be HiLo of course, and it could only > >> use a table, not a sequence. > >> > >> /Oskar > >> > >> > >> 2011/2/2 Jason Dentler <[email protected]>: > >> > Here's my guess: All the hilo-style generators should use the same > >> > algorithm. Internally, the SequenceHiLo generator uses a sequence to > >> > ensure > >> > each sessionfactory gets its own next hi value. Therefore, the hi > value > >> > must > >> > increment by one. > >> > Thanks, > >> > Jason Dentler > >> > On Wed, Feb 2, 2011 at 3:51 PM, Nick <[email protected]> wrote: > >> >> > >> >> As I understand it, the HiLo algorithm for ID generation essentially > >> >> uses this formula: > >> >> > >> >> NextID = (Hi * Lo) + (++Counter) > >> >> > >> >> Hi is stored in the database, Lo is configured as part of the > entity's > >> >> mapping, and the Counter is just maintained in memory within the ID > >> >> generator. Whenever Counter exceeds Lo (as new IDs are assigned to > >> >> entities), a new Hi value is fetched, and Counter is reset. Also, all > >> >> applications creating this entity basically have to use the same Lo > >> >> value to avoid potential ID collisions, given how this formula > >> >> evaluates. > >> >> > >> >> What I don't understand is the advantage this would have over simply > >> >> storing a maximum ID as the Hi value, and incrementing it by the > batch > >> >> size you expect to use (instead of by 1). You would still need to > >> >> fetch a new Hi value every time you run out of IDs, but there's no > >> >> need to coordinate the batch sizes across applications, or across > >> >> time. > >> >> > >> >> For example, if the current Hi value is 1, an application could lock > >> >> and update that to 11 (batch size = 10), thereby safely ensuring it > >> >> can safely assign IDs 1-10. Another application could lock and update > >> >> it from 11 to 101 (batch size = 90), thereby ensuring that it can > >> >> safely assign IDs 11-100. > >> >> > >> >> In either approach, locking of the Hi value in the database before > >> >> updating it is crucial. But either approach would need to do the same > >> >> number of database queries to fetch new Hi values (assuming the same > >> >> batch sizes), and a "Max ID"-style approach has the additional > >> >> flexibility of allowing the batch size to differ between > applications, > >> >> or over time. > >> >> > >> >> What is the advantage of HiLo here? I feel like I must be missing > >> >> something obvious. > >> >> > >> >> -- > >> >> 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]<nhusers%[email protected]> > . > >> >> For more options, visit this group at > >> >> http://groups.google.com/group/nhusers?hl=en. > >> >> > >> > > >> > -- > >> > 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]<nhusers%[email protected]> > . > >> > For more options, visit this group at > >> > http://groups.google.com/group/nhusers?hl=en. > >> > > >> > >> -- > >> 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]<nhusers%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/nhusers?hl=en. > >> > > > > > > > > -- > > Fabio Maulo > > > > -- > > 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]<nhusers%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/nhusers?hl=en. > > > > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- Fabio Maulo -- 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.
