If I well remember I have something in my own TODO list of generators (rollback identifiers).There is something similar using Table-based-id generator. Btw that generator is not so hard to implements even is I don't like full-server-side generator ID. The only one full server side I like is sequence (ORACLE, Firebird and all others RDBMS supporting sequence); sequence need an hit to DB but does not break UoW.
2009/5/26 Bill Barry <[email protected]> > 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. > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
