Oh ok i see what you mean with winforms. Might be correct but the thing is that winforms application can be a bit slower, and you can have a smaller range. Or you can implement your own generator as usual.
Tuna Toksöz Eternal sunshine of the open source mind. http://devlicio.us/blogs/tuna_toksoz http://tunatoksoz.com http://twitter.com/tehlike On Tue, Sep 15, 2009 at 1:25 PM, Delucia <[email protected]> wrote: > Tuna, I agree with your responses to 1,2,3. For #4 it is better for winform > application restarts the Lo count is lost from the TableHiLoGenerator > instance and has to increment the hi to get a new range. For a web > application that's not an issue because it's rarely restarted. see my first > post for example. > Thanks > > > On Tue, Sep 15, 2009 at 12:28 PM, Tuna Toksoz <[email protected]> wrote: > >> Inline >> 1. It requires less trips to database because next_hi is not done per >> table, hence more efficient. >> >> Efficiency is correct, but it is not of crucial importance. One query per >> entity type (or table whatever), and their ranges will be consumed more >> slowly than your previous one. >> >> 2. much less fragmentation in the ids because the session factory will >> manage the range of keys to be consumed totally. >> Don't agree, your entities will have 1,200,350,600,1000 kind of ids while >> in hilo per entity approach you have 1,2,3,4 --- 601,602,603 >> >> >> 3. easier to mimic for outside NH for other applications that use the >> database. >> Still easy to do it outside NH. >> >> 4. works much better for winforms applications. >> I don't get it. >> >> >> >> Tuna Toksöz >> Eternal sunshine of the open source mind. >> >> http://devlicio.us/blogs/tuna_toksoz >> http://tunatoksoz.com >> http://twitter.com/tehlike >> >> >> >> >> On Tue, Sep 15, 2009 at 12:17 PM, Delucia <[email protected]> wrote: >> >>> I can do it in a custom generator but I think it has general use that can >>> benefit all NH users. Here why the what I'm proposing is better than the >>> TableHiLoGenerator. >>> 1. It requires less trips to database because next_hi is not done per >>> table, hence more efficient. >>> 2. much less fragmentation in the ids because the session factory will >>> manage the range of keys to be consumed totally. >>> 3. easier to mimic for outside NH for other applications that use the >>> database. >>> 4. works much better for winforms applications. >>> >>> Also, since the TableHiLoGenerator allows specifying a different max_lo >>> per table then it doesn't guarantee unique id's per database. >>> >>> I looked at the code and found SequenceHiLoGenerator which maybe does >>> what I'm suggesting but I'm not sure. Unfortunately i can't use it with >>> mssql server though. >>> >>> >>> On Tue, Sep 15, 2009 at 11:49 AM, Fabio Maulo <[email protected]>wrote: >>> >>>> 2009/9/15 Delucia <[email protected]> >>>> >>>>> >>>>> 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. >>>>> >>>> >>>> Not, it don't. You can do it in a custom generator. >>>> >>>> -- >>>> 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 -~----------~----~----~----~------~----~------~--~---
