Mike: I admit being confused by this. What is the semantic meaning of NULL as a version number? How can NH use NULL as a version of a retrieved entity? NH would need to compare the current version to NULL in order to determine if optimistic concurrency has been violated on save/update. This seems to me to be a meaningless comparison.
Bottom line: if the record in the DB has an invalid (meaningless, as in the case of NULL) VERSION value then you need to correct that value before you can use NH's support for VERSION numbers. IMO NH *should* throw when it encounters such a condition as it is an "invalid" state for the system to be in. Am I misunderstanding the use-case here? Can you help me better understand this? Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Fri, Apr 22, 2011 at 5: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 >
