Unique identifiers are also considered the devil since they apparently don't replicate (which I've never heard of) and they are slow. guid.comb is extremely efficient but he wouldn't hear anymore about it.
The current insert sprocs do the following INSERT INTO Table(ID, SomeColumn) WITH(XLOCK) VALUES( ISNULL(MAX(ID), 0) + 1, @SomeColumn ) On May 26, 4:57 pm, "[email protected]" <[email protected]> wrote: > Actually, I almost like Markus' idea. Thanks for that. I think I > could add a default to the column in the DB. I'm not sure how this > would handle criteria queries Expression.IsNull(child.Parent) etc. A > lazy load of a many-to-one would still load up the placeholder record > which is not ideal. > > The problem with the app I'm working on is that the DBA has a death > grip on the database which is causing the dev group to be in a version > lock because the database needs to update with every module/ > application release due to everything being in stored procedures and > views. We're unable to do parallel development on several modules/ > apps at the same time that use the same database schema. The argument > that views & sprocs allow for abstraction is untrue for the most part. > > On May 26, 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
