ehm!! Inconsistent data in the DB does not mean that NH have to do a miracle. We said, more than once, that you have to validate your schema with what you have mapped. If in NH expect a not nullable column you have to have a not-nullable column.
Instead report a bug in NH you should set that column as not-nullable and all applications putting their hands in a single db (instead use a service, at least, to validate data) should respect the same rules. Let me make you another example: You have a property of type Int32 mapped to a nullable column (that is fine especially when you work with TablePerClassHierarchy). When you store a entity with NHibernate that column will have always a value because in Int32 can't be null. Another application may use another concept as, for instance, when zero store null. Now let NH upload that entity; NH will upload a null but the value in your object is zero. When you flush the session NH will run an update even when you don't touch your entity. Now try to say me that this, and your reported issue, is a bug in NH and not a completely confusion in your system. On Fri, Apr 22, 2011 at 6:43 PM, Mike Pontillo <[email protected]> wrote: > Sorry, > > Looks like I used the wrong mailing list for this. Re-forwarding; > apologies. > > Mike > > > ---------- Forwarded message ---------- > From: Mike Pontillo <[email protected]> > Date: Fri, Apr 22, 2011 at 1:37 PM > Subject: Fwd: [NHJIRA] Closed: (NH-2668) REOPEN: Version properties > which are NULL in the database cause exceptions during a delete or > update > To: [email protected] > > > OK, > > I guess this needs to be taken to the mailing list. Apparently mere > mortals like myself have no ability to comment on JIRA issues. > > I am very surprised that this issue was closed so quickly. Not > everyone writing an application using NHibernate is operating under > the assumption that NHibernate is the only thing that ever > creates/updates/deletes rows in that database. One of the reasons you > have a database is so that you can have a tiered architecture, with > multiple applications interacting with the database. Closing it > because "This is not a bug in NH you have only dirty values, not wrote > using NH, in your DB." doesn't make sense. The values are not dirty. > The fix merely hardens NHibernate so that it can operate better in > conditions where it is *NOT* the only application interacting with the > database. > > Fabio, I am dropping the not-null constraint so that the test case > reflects the real-world use case I am testing against: that is, I am > using NHibernate against a database that does *NOT* have not-null > constraints on its version properties. > > What is the path forward here? I can keep a fork of NHibernate for > my company's internal use, but I'd rather contribute the fixes I make > back to the community, so everyone can benefit from them. > > Regards, > Mike > > > ---------- Forwarded message ---------- > From: Fabio Maulo (JIRA) <[email protected]> > Date: Fri, Apr 22, 2011 at 1:28 PM > Subject: [NHJIRA] Closed: (NH-2668) REOPEN: Version properties which > are NULL in the database cause exceptions during a delete or update > To: [email protected] > > > > [ > http://216.121.112.228/browse/NH-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Fabio Maulo closed NH-2668. > --------------------------- > > Resolution: Won't Fix > > > REOPEN: Version properties which are NULL in the database cause > exceptions during a delete or update > > > ---------------------------------------------------------------------------------------------------- > > > > Key: NH-2668 > > URL: http://216.121.112.228/browse/NH-2668 > > Project: NHibernate > > Issue Type: Bug > > Components: Core > > Affects Versions: 2.1.2.GA, 3.0.0.Alpha1, 3.0.0.Alpha2, 3.0.0.Alpha3, > 3.0.0.Beta1, 3.0.0.Beta2, 3.0.0.CR1, 3.0.0.GA, 3.1.0, 3.2.0Alpha1, > 3.2.0Alpha2 > > Reporter: Mike Pontillo > > Priority: Major > > Attachments: NH2667-fix.patch, NH2667-TestCases.patch > > > > > > Reopening NH-2667 as a new defect since it appears that I cannot reopen > it myself. NH-2667 was closed before I could even attach the test case. > Please don't close this yet; let the test case speak for itself. > > I tried using unsaved-value and it did not work. There are, in fact, bugs > here. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the > administrators: http://216.121.112.228/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > -- Fabio Maulo
