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 -~----------~----~----~----~------~----~------~--~---
