That's easy to do, with the "where" parameter.
The main drawback is that you have to seed it manually when creating the
schema.

Also, why would you care about the table count?
It's just an implementation detail; these tables act as sequences in
databases that don't support them (where they do, you can use seqhilo
instead)

    Diego


On Mon, Sep 13, 2010 at 10:29, Thomas Koch <[email protected]> wrote:

> Nice trick. I am not sure I like the idea of having a separate table,
> though ... actually I am sure I dont like it.  :-)
>
> To begin with I was investigating whether or not it would be possible
> to have a separate row for each table.
>
> That would of course require an extra column for the entity name. I
> did not find any solutions to this.
>
> Thomas
>
>
>
>
> On 13 Sep., 14:16, Jason Meckley <[email protected]> wrote:
> > the read/write of hilo uses a record level lock, so you don't need to
> > worry about 2 session pulling the same hi value. you can also override
> > the hilo table name in the mapping. I like to give each entity which
> > uses hilo it's own separate table.
> > Customer, Customer_HiLo
> > Order, Order_HiLo
> > Foo, Foo_HiLo
> >
> > On Sep 13, 3:44 am, Thomas Koch <[email protected]> wrote:
> >
> >
> >
> > > Well, using NHProf (why didn't I think of that before?)
> >
> > > So to answer my own question "no there is no reace condition"
> >
> > > Details:
> >
> > > 1)
> > > begin transaction with isolation level: Unspecified
> >
> > > 2)
> > > Reading high value:
> > > select next_hi
> > > from   hibernate_unique_key with (updlock ,rowlock)
> >
> > > 3)
> > > Updating high value:
> > > update hibernate_unique_key
> > > set    next_hi = 1590 /* @p0 */
> > > where  next_hi = 1589 /* @p1 */
> >
> > > 4)
> > > Reading high value:
> > > select next_hi
> > > from   hibernate_unique_key with (updlock ,rowlock)
> >
> > > 5)
> > > Updating high value:
> > > update hibernate_unique_key
> > > set    next_hi = 1591 /* @p0 */
> > > where  next_hi = 1590 /* @p1 */
> >
> > > 6)
> > > Inserting my order
> >
> > > 7)
> > > Insert an address
> >
> > > 8)
> > > commit transaction
> >
> > > The reason I am seeing two updates of the key table is that each
> > > entity gets its own high value.
> >
> > > Thomas
> >
> > > On 10 Sep., 14:05, Fabio Maulo <[email protected]> wrote:
> >
> > > > since the source of "high" is concentrated in one place.... ;)
> >
> > > > On Fri, Sep 10, 2010 at 8:58 AM, Thomas Koch <[email protected]>
> wrote:
> > > > > Hi - I use the hi-lo generator for my domain and have a question
> > > > > regarding its use in multiple processes.
> >
> > > > > I have a WCF project that is the primary power behind generating
> > > > > entities and saving them to the database with NHibernate and HI-LO.
> I
> > > > > also have an administrative application that sometimes generate
> > > > > entities for the domain.
> >
> > > > > Since these two applications live en separate processes, is there a
> > > > > risk here of them creating overlapping id's ?
> >
> > > > > As far as I have understood, each session factory will update the
> > > > > "hibernate_unique_key" table and generate ids based on the "high"
> > > > > value returned.
> >
> > > > > Can the reading and updating of this "next high value" be
> considered
> > > > > an atomtic operation even though its done in separate processes?
> >
> > > > > Regards
> > > > > Thomas
> >
> > > > > --
> > > > > 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]>
> <nhusers%[email protected]<nhusers%[email protected]>
> ­­>
> > > > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/nhusers?hl=en.
> >
> > > > --
> > > > Fabio Maulo- Skjul tekst i anførselstegn -
> >
> > > > - Vis tekst i anførselstegn -- Skjul tekst i anførselstegn -
> >
> > - Vis tekst i anførselstegn -
>
> --
> 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].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to