Ah...The point where strat is the SchemaUpdate of the TRUNK... 2008/11/13 Fabio Maulo <[EMAIL PROTECTED]>
> 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 >> >> >> >> >> >> >> >> > > > -- > Fabio Maulo > -- Fabio Maulo
