Hi Fabio, yes and no. I have to develop against a huge and old legacy database and i dose not have the option to change the database.
Hmm and this points me to another problem. I dont want to have a nullable property there, because the field is only nullable for old data and not for new (because i cant change the table schema) so i can run a "SchemaVerify" (if this tools would exists) and i get the error, but since i dont want to change my property to nullable i have still the ghosting problem. Wouldn't it here a good suggestion to add an per property option which forces nhibernate to eval DBNull.Value==default(T) if it dose a dirty check? Steve Fabio Maulo schrieb: > Hi Steve.I think your are talking about another tool. > So far we have SchemaExport and SchemaUpdate. > I think your are talking about "SchemaVerify" that would be very useful for > legacy DB. > A good point where start is SchemaUpdate because there you have all > artifacts to read the schema from DB and all to read NH-metadata. > Very good idea Steve; it would be a very useful new feature. > > 2008/11/13 Steve Wagner <[EMAIL PROTECTED]> > >> As i read Fabios' article >> >> >> http://nhforge.org/blogs/nhibernate/archive/2008/10/20/how-test-your-mappings-the-ghostbuster.aspx >> >> i remind me that i ran into this problem a few month ago in a very bad >> point of my project (from time perspective). My problem was that there >> was a property which was int and not nullable but the database field was >> null. So the entity which should never gets flushed was flush in the >> database. >> >> So now as i think about it, there is the question: Why has the >> NHibernate Core no way to prevent or detect it?!? >> >> I see two ways for that: >> >> 1. NHibernate should set all mapped propertys and the after that it >> should use the property value instead of the database values for the >> isDirty checks. >> >> This may could have side effects. >> >> 2. NHibernate should have a build in mechanism which checks the mapped >> property value and the database value after the object was load and >> throw an exception if the values are different. Since this lead to a >> slower performance it should be configurable so a developer can decide >> to activate it only in debug and test builds. >> >> Before i put an invalid issue in jira i wants to discuss this here :-) >> >> Steve >> >> >> >> >> >> >> >> > >
