This is almost exactly what NH Increment generator does, hilo takes it further. BTW, you can set capacity (maxLo) for HiLo generator, if that makes your dba happy, this will have even less gaps.
Why do those DBAs are careful about it? You have quantillions(10^18) of IDs when using long! Tuna Toksöz Eternal sunshine of the open source mind. http://devlicio.us/blogs/tuna_toksoz http://tunatoksoz.com http://twitter.com/tehlike On Wed, May 27, 2009 at 12:21 AM, Bill Barry <[email protected]>wrote: > Guessing from the sounds of it he is like our dba. He wants ids to be > generated in order no matter what and not to skip any if something happens > like a transaction failure. > > Our dbs have a special table in them called next_id. This table has 1 row > and a column for each table with an id generated this way. > > the procedure for inserting is as follows: > > lock the next_id table > grab the next_id column + 1 for the table you want to write to > insert into this table > update the next_id table > release the lock on this table > complete transaction > > (yes this means that we have a global lock in our database and that every > insert to all of these tables must be done in serial). This all stems from > some old client requirement that our data is stored this way. We have some > 300+ dbs that follow this pattern (all of which have the same schema, just > for different data). This schema is not mapped with NH at all (two other > schemas, each with many databases on their own though are mapped) > > > Greg Young wrote: > > What *does* he want with ids if not hilo and not sequences or guids? > > Cheers, > > Greg > > On Tue, May 26, 2009 at 4:50 PM, [email protected] < > [email protected]> wrote: > >> >> 1) It would be nice to work with nullable datetimes in the code since >> that is a "not set" scenario to object guys. I've already made the >> user type that converts to/from the DB. It is easy and clean and >> makes both parties happy. >> 3) oh he hasn't accepted it yet. The argument being that it leaves >> gaps in the IDs. If we have a bigint and the apps restart once a day, >> it isn't going to leave alot of gaps in the IDs. I offered him unique >> identifiers but we all know that didn't go anywhere. >> 4) I've thought about adding a where map attribute to all the child >> associates which I dislike and that doesn't solve the many-to-one >> scenarios. I'm thinking I can override ManyToOneType & OneToManyType >> to translate zero to null from the DB and NULL to 0 at the DB. To >> prevent NH from thinking it is a new record, I'll probably have to set >> unsaved-value = -1 or something weird like that. This is a stupid >> requirement from the DBA imo! >> >> On May 26, 3:45 pm, Fabio Maulo <[email protected]> wrote: >> > 1) you don't need a custom user type (a DateTime had a value)2) you >> don't >> > need a custom user type (assign string.Empty to the property in the >> Ctor) >> > 3) Alleluia!!! a DBA accepting HighLow >> > 4) here you really need to do something. Zero is a value and even if you >> can >> > use not-found="ignore" NH will try to get it before ignore (mean an >> > additional SELECT)... in my mind no relation mean no value... but you >> know >> > I'm not a DBA or, at least, I'm an ORM-oriented guy. >> > >> > Try to convert ithttp://www.agiledata.org/essays/dbaSkills.html >> > >> > 2009/5/26 [email protected] <[email protected]> >> > >> > >> > >> > >> > >> > > I work with an extremely difficult SQL Server DBA that hates anything/ >> > > everything that is not a stored procedure. However, he's started >> > > coming around and but has still placed the following constraints. >> > >> > > 1) Dates must be small datetime and NON-nullable. Nullable dates are >> > > equal to 1900/1/1. Easy enough to get around with a nh usertype for >> > > querying and persistence. >> > > 2) Strings/VARCHAR must be non-nullable. Also very solvable via empty >> > > string nh user type. >> > > 3) Idents are evil and will not be used. Easy to get around with >> > > hilo. >> > > 4) Now for the tough part which is where my question is. All >> > > associations that are NULLABLE actually link to a "placeholder" record >> > > with ID 0. What would the community guys recommend? That I override >> > > the ManyToOne and OneToMany types to deal with this or do you have a >> > > better suggestion? >> > >> > > I have used NHibernate for several years now without ever so much as a >> > > blip of a problem. NHibernate is an ideal tool for the company I'm >> > > with now assuming I can get around these DBA related issues. Has >> > > anyone ever heard of some of these bizarre requirements and how did >> > > you deal with them? >> > >> > -- >> > Fabio Maulo >> >> > > > -- > It is the mark of an educated mind to be able to entertain a thought > without accepting it. > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
