Thanks Anne for the explanation. I guess, if I understood you correctly, a sequence is similar to hilo algorithm but the difference is that a sequence reserves only one id while hilo reserves a range of ids. the advantage of that is that it allows the unit of work pattern to work in diconnected mode from the database. What I'm proposing for the hilo algorithm is that the session factory becomes responsible for reserving a range of Id's using hilo and then it will make this range available for all session to use on all entities.
This will require a change to the current implementation where the hilo is specified per entity mapping and I think it should be specified per session factory. On Tue, Sep 15, 2009 at 10:36 AM, Anne Epstein <[email protected]> wrote: > A sequence is a structure in Oracle that is JUST a counter, with properties > useful to a counter. You can specify a starting number, max number, I > believe you can specify how many you want it to step up at a time. You might > think it's like a juiced-up autoincrement column, but it's not-a sequence > can happily exist without ever being used/associated with any table. Every > time you ask it for a number, it'll give you a new (different) number. > That's all it does. > > A typical usage would be for generating ids for a sql insert in a stored > procedure. You'd first get a number from a sequence, and then insert your > new row, using the number from your sequence as the id. Clearly, for this to > not be a problem, you'd want to make sure that only one sequence is ever > used for a particular table, or you'd risk collisions... though I don't > think there's any reason you couldn't use one sequence for multiple tables. > NHibernate has a similar ability to set a sequence as an id generator in the > mappings, and it works well. An aspect of sequences that some might see as > a disadvantage is that though they come out of the sequence as dictated by > the sequence specs they don't care about the row they could be attached > to-unlike identity in SQL Server, there's no promise the identifiers pulled > from a sequence end up in "insert" order in a table. If you had several > processes that did inserts, they might, get sequence ids 3 and 4, but then 4 > could end up getting inserted first. OR.... if there's an error after the > sequence call, the sql call to insert 3 might not get run at all, and there > might never be a 3 row-again, unlike SQL Server identity, where the next id > in order is only used up on successful insert.. > > > > > On Tue, Sep 15, 2009 at 8:55 AM, Delucia <[email protected]> wrote: > >> sequence like in oracle? well i never used oracle so I don't know how it >> works. can you elaborate more? >> >> On Tue, Sep 15, 2009 at 8:30 AM, Fabio Maulo <[email protected]>wrote: >> >>> no. I mean sequence. >>> >>> 2009/9/15 Delucia <[email protected]> >>> >>> I'm not sure what exactly sequence-like mean. do you mean like identity >>>> columns in mssql? in any case what I mean is that the algorithm should be >>>> that the session factory reserves a range of keys by incrementing the >>>> next_hi and then this range will be available for all session to use on all >>>> entities and when the session factory consumes the range it reserves >>>> another >>>> one and so on. >>>> this is an easier algorithm than the current one that reserves a range >>>> per table and works better for winform applications. >>>> >>>> On Tue, Sep 15, 2009 at 12:10 AM, Fabio Maulo <[email protected]>wrote: >>>> >>>>> do you mean a sequence-like generator ? >>>>> >>>>> 2009/9/14 Delucia <[email protected]> >>>>> >>>>>> >>>>>> Fabio, you're absolutely right. I meant winform application in my >>>>>> example. I know that bigint has a lot of room but what about saving >>>>>> trips to the database. >>>>>> >>>>>> I have not looked at the HiLo implementation in NH but I think what is >>>>>> happening is that the SessionFactory is keeping the count of the last >>>>>> used id per table. so from the above example: >>>>>> >>>>>> using (var session = SessionSource.CreateSession()) >>>>>> { >>>>>> using (session.BeginTransaction()) >>>>>> { >>>>>> var customer = new Customer("Joe"); >>>>>> >>>>>> // this is asking the session factory for the next id >>>>>> // the sesion factory has nothing so it increments the next_hi >>>>>> in the database and returns 1001 >>>>>> session.SaveOrUpdate(customer); >>>>>> >>>>>> var customer2 = new Customer("Shmoe"); >>>>>> // this time the session factory has an availabe id value for >>>>>> the Customer entity type >>>>>> // and returns 1002 >>>>>> session.SaveOrUpdate(customer2); >>>>>> >>>>>> var employee = new Employee("Jack"); >>>>>> >>>>>> // for this entity type the session factory has no value and it >>>>>> has to increment the next_hi in the database >>>>>> // and return 2001 >>>>>> session.SaveOrUpdate(employee); >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> I think this is not only inefficient but unnecessarily complicated and >>>>>> this complexity effects generating id values outside NH (you have to >>>>>> think about SSIS packages and what not). I think an easier and more >>>>>> effiect alternative if the SessionFactory does not keep track of id >>>>>> per table but per database. This way the third call to save the >>>>>> employee will return 1003 instead of 2002 and save a trip to the >>>>>> database and use less keys. In addition it is easier to implement >>>>>> outside NH because it doesn't have to know about the table it is >>>>>> accessing. >>>>>> >>>>>> >>>>>> On Sep 14, 6:09 pm, Fabio Maulo <[email protected]> wrote: >>>>>> > btw Delucia that is an improvement of HighLow defined in ORM >>>>>> theory.The >>>>>> > target of the improvement is : has a less fragmentation per table. >>>>>> > >>>>>> > In winform and 2 physical tiers you should use a little max-low >>>>>> (like 99) >>>>>> > >>>>>> > 2009/9/14 Delucia <[email protected]> >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > > Currently if I want to insert an object graph that has 2 entities >>>>>> that use >>>>>> > > HiLo for their Id, NH session will go to the database for two >>>>>> times, one >>>>>> > > time for each entity, and increment the next_hi count. I was >>>>>> assuming that >>>>>> > > the session will have to go once to the database and reserve a >>>>>> range to be >>>>>> > > used for all entities since all entities are using the same >>>>>> next_hi value >>>>>> > > that will guarantee they will not collide. here is an example: >>>>>> > > using (var session = SessionSource.CreateSession()) >>>>>> > > { >>>>>> > >>>>>> > > using (session.BeginTransaction()) >>>>>> > > { >>>>>> > > var customer = new Customer("Joe"); >>>>>> > >>>>>> > > session.SaveOrUpdate(customer); >>>>>> > >>>>>> > > var employee = new Employee { FirstName = >>>>>> "Sue", >>>>>> > > LastName = "Wong" }; >>>>>> > >>>>>> > > session.SaveOrUpdate(employee); >>>>>> > > } >>>>>> > >>>>>> > > session.Transaction.Commit(); >>>>>> > > } >>>>>> > > } >>>>>> > >>>>>> > > Given the max_Lo is set to 1000, this code will go to the database >>>>>> twice to >>>>>> > > increment the next_hi one time for the customer and one time for >>>>>> the >>>>>> > > employee. I think it should increment it only once per session. >>>>>> > >>>>>> > -- >>>>>> > Fabio Maulo- Hide quoted text - >>>>>> > >>>>>> > - Show quoted text - >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Fabio Maulo >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> 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 -~----------~----~----~----~------~----~------~--~---
