Increment isn't safe to use for multiple app domains. HiLo is ultimate all-round IMO. I can do batch inserts from NH and they don't collide across appdomains. I usually set the max_lo to 500 as I've found that to be ideal and it makes the gaps small though I don't consider the gaps an issue.
The real pain for me is this placeholder/0 ID record idea. On May 26, 5:25 pm, Tuna Toksoz <[email protected]> wrote: > 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_toksozhttp://tunatoksoz.comhttp://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 -~----------~----~----~----~------~----~------~--~---
