views:

591

answers:

2

Basically I'm trying to do the same thing as this question but with Fluent NHibernate.

Here is my id generation convention:

    public class IdGenerationConvention : IIdConvention
    {
         public void Apply(IIdentityInstance instance)
         {
              instance.GeneratedBy.HiLo("1000");
         }
    }

Now this works great, but all classes end up using the same next_hi.

    create table hibernate_unique_key (
            next_hi INTEGER 
    )

Does anyone know how to specify that each class should use it's own next_hi?

To clarify, I'd like to end up with something like customer_next_hi and order_next_hi, assuming it works based on columns. If it's row based then that's fine too, provided each entity knows which row to use for it's next_hi value.

A: 

I also asked this question in the Fluent NHibernate Google Group and it appears that the only way to do this would be to create a custom id generator class that either inherits from HiLo or TableGenerator. From what I gather, the key issue is that the SQL statement to create the seed table is only executed once, and there isn't a built-in override or hook to get it to create entity specific columns or rows.

So something along the lines of this is what I'll need to do. I'll post more once I have a working implementation.

Sean Gough
Interesting concept. I'd definitely love to see it once it's working. Be sure to post back!
ddc0660
The biggest PITA so far is determining all the entity columns in advance. The linked solution relies on an "allcolumns" parameter where you specify the various seed columns you need. I'd like it to be more dynamic though.
Sean Gough
A: 

Interesting question, but I wonder why you want to do it? On the (fairly minor) downside you would be generating more db requests. On the upside you would be increasing your surrogate ID space by some factor. But isn't Long/BigInt enough for them all combined? (max 18,446,744,073,709,551,615 ids!)

UpTheCreek
For the most part I agree, not a whole lot of gain to be had and this kinda falls into the "if it ain't broke" category. To answer your question though, I think part of it is having IDs increment on a per entity basis (for situations like 1000 orders being added in between adding two customers). The other part I admit is just seeing how it can be done. :)
Sean Gough
Yeah, I see what you mean regarding the order numbers. There is however a school of thought that says surrogate keys should not have any use or meaning outside of the application (i.e. the ID field should not serve as both the surrogate key and the order number). Another problem of using the ID for both purposes is if you have to rethink your database approach (when scaling for instance) and need to move to a different key strategy (but still keep the old records).
UpTheCreek
Hmm, that SOT makes a lot of sense and I think those are very valid points. I'm still gonna try and get it working though, if for no other reason than getting a better idea of the inner workings.
Sean Gough

related questions