Search code examples
c#.netstringnhibernatenhibernate-mapping

Could not find the property - exception after switching from NHibernate 3 to 3.3.1


I have a class with a field:

    protected DateTime insertDate;

This is mapping for this fiels:

    <property name="InsertDate" access="field.camelcase" update="false" />

This field is set when with ctor

    public DocuBase(DateTime insertDate)

and is persisted only when row is added to the database. I don't need property for it at all, no setter & no getter. I worked in NHibernate 3.

And now, I've moved from NHiberbate 3 to NHibernate 3.3.1, and I get this exception when session factory is created:

Could not find the property 'InsertDate', associated to the field 'insertDate', in class 'XXXX'

Why is is happening & how can I change mapping in order to get rid of the exception?

EDIT: Below answer is completly correct. But for those of you that don't need/don't want to have a property, and only field, there's another solution:

  • set name attribute to field name (in my case it is insertDate) and remember to have correct column name

    <property name="insertDate" column="InsertDate" access="field.camelcase" update="false" />
    

Solution

  • It is case sensitivity, this will work.

    <property name="insertDate" column="InsertDate" update="false" />
    

    Looks like in release 3.1.0, there was a breaking change

    NH today accepts code below. It would be better if this would throw - it causes problem when configurate NH (or 3rd party tools) other ways than by hbm, using the property name (or memberinfo) of the public interface.

    [hbm]
    <property name="Name" access="field.camelcase" />
    
    [code]
    string name;
    public virtual string SomeThingCompletelyDifferent{
                                      get {return name;}
                                      set{name=value;}
    }
    

    Note: This will be a breaking change.

    ps - updated answer to remove reference to use Property with private set as this was not what was being looked for and above breaking change is more relevant.