5

I have a solution that was created with NHib 1.2 which we're upgrading to NHib 3.0.

Our hbm file has the following property:

<property name="ContentId" column="ContentId" access="field.camelcase-underscore" />

The class doesn't have a ContentId property. This was working fine in NHib 1.2 but now we're getting getting the following exception:

Could not compile the mapping document: XXXX.Core.Domain.Video.hbm.xml ---> NHibernate.MappingException: Problem trying to set property type by reflection ---> NHibernate.MappingException: class Core.Domain.Video, Core, Version=1.0.0.29283, Culture=neutral, PublicKeyToken=null not found while looking for property: ContentId ---> NHibernate.PropertyNotFoundException: Could not find the property 'ContentId', associated to the field '_contentId', in class 'Core.Domain.Video'.

Why would this stop working? Is it still supported in NHib 3?

We have many many properties like this that we might need to add.

user229044
  • 232,980
  • 40
  • 330
  • 338
big_tommy_7bb
  • 1,257
  • 2
  • 21
  • 37

2 Answers2

10

NHibernate greatly improved its error messaging and diagnostics in NH2.X and again in NH3.X. You are telling NHibernate that you have a property and you want to map it via field access to a field named by _camelCase convention. You don't have a property named ContentId and NHibernate is letting you know that you lied to it. :)

Try updating your mapping to:

<property name="_contentId" column="ContentId" access="field" />

You will need to update any HQL or Criteria queries to use _contentId rather than ContentId. Another option would be to add a private ContentId property.

James Kovacs
  • 11,549
  • 40
  • 44
  • Thanks James. Shame that NHibernate changed this, makes upgrading a large domain model that used this functionality in 1.2 a pain. From NHib in Action: ..XML.. ...when writing NHibernate HQL queries, you use the more readable property name ... Behind the scenes, NHibernate knows to bypass the property and instead use the field when loading and saving objects. Because you’re using a field, the property is effectively ignored—it doesn’t even have to exist in the code! – big_tommy_7bb May 09 '11 at 09:06
  • NHibernate in Action is a very good book, but quite a bit has changed since NH1.2 (used by the book). I can fully understand why the NH team added those more rigorous checks. Most of the time a mismatch between the class definition and the mapping is an error. – James Kovacs May 12 '11 at 16:31
  • This answer makes it sound like nhibernate didn't change to be backwards incompatable with old mapping when it did. If you had default-access="field.camelcase-underscore" in your mapping and specified a property of "Bla", then only having a property named '_bla' in your domain class, would work. Upgrading to nhibernate3, it stops working. The solution suggested here is fine - I'm about to add properties as described to about 60 classes. – PandaWood Jul 13 '11 at 07:15
  • In fact, I believe it's fair to say that default-access="field-camelcase-underscore" is effectively no longer supported in nhibernate3 – PandaWood Jul 14 '11 at 00:22
1

I'd like to provide information which helped me answer this question:

http://groups.google.com/group/nhusers/browse_thread/thread/e078734a221c3c0c/ec8b873b385d4426?lnk=gst&q=field+camelcase+underscore#ec8b873b385d4426

In this link Fabio explains the same problem you are having like this:

This mapping

<property name="PositiveValue" access="field.camelcase-underscore" />

mean: For my property named "PositiveValue" you (NH) have to access to the field; to discover which is the associated field you (NH) have to use the strategy "camelcase-underscore".

If there is no property you can't use the accessor with a specific strategy.

Which struck me as a little odd because it meant adding dummy, unused properties, just to make the nhibernate3 compiler happy. The underlying functionality is the same.

PandaWood
  • 8,086
  • 9
  • 49
  • 54