NHibernate throws "Cannot resolve property:", but the property does not exist * ANYWHERE * in the project

Question

I get a strange problem with nHibernate ... I get this exception:

Unable to resolve property: _Portal 

when I try to pass an object graph. The strange thing is that when I look at the whole solution, I don't seem to have this particular property in the project ?!

Has anyone come across this particular case, and if so, what did they do to solve it?

Answer 1

I encountered the same problem after upgrading nHibernate to 3.3 (from 3.1), as well as related libraries (including FluentNhibernate). I have a parent object with a child collection, and when modifying the child collection, it throws the same exception that you received (with the property name nonexistant "_Namespace", where the "namespace" was the first part of my actual namespace).

In our case, switching to SaveOrUpdate () is not an option, since we really have a version of this object loaded into the session, so we need Merge ().

I do not know what other similarities may be. For us, this is a parent with a child collection using FluentNhibernate. The mapping of the parent is Cascade.AllDeleteOrphan () for the child, and for the child, the parent, Cascade.None ().

Unfortunately, I cannot find any other messages about this error, so the solution for us was to simply return to nHibernate 3.1 (and its associated binaries such as FluentNhibernate and Iesi.Collections). This is the only change, and then it works great.

Update by bug registered with JIRA [3234].

An error has been registered in JIRA. The question has not yet received any priority. Perhaps if you encounter this problem, you can create an account and vote to fix the error. https://nhibernate.jira.com/browse/NH-3234

Workaround update for JIRA error [3234].

According to Ondrej's comment about the error, overriding the standard merge listener in the session configuration using this code solves the problem at the moment. I am sure that a workaround will be published shortly.

 public class UniDirectionalMergeFixListener : DefaultMergeEventListener { protected override IDictionary GetMergeMap(object anything) { var cache = (EventCache)anything; var result = IdentityMap.Instantiate(cache.Count); foreach (DictionaryEntry entry in cache) result[entry.Value] = entry.Key; return result; } } 

Answer 2

So, I solved my problem, but I'm not sure why this was the resolution.

In my project, I abstracted the use of nHibernate in my own project (* .Objects.nHibernate is a namespace). I did this because the client I work with usually doesn't use nHibernate, and I'm trying to get them on board using it.

What happens is that in this project there are several data models that are added only to the system ... for example, we never update. So, my "repository" should take this into account.

In my Commit () function in the repository, I serialize the object graph and then deserialize it to make a copy of the object to save. What I was doing was telling the session "_Session.Merge (...)" when I needed to say "_Session.SaveOrUpdate (...)" to make things fix the database correctly ... uncertainty about why made a difference, but that was the answer for the last two days.

thanks. for your help Rippo and Nickolay!

Answer 3

A workaround for this problem is to infer from DefaultMergeEventListener and override the following method:

  protected override IDictionary GetMergeMap(object anything) { var cache = (EventCache) anything; var result = IdentityMap.Instantiate(cache.Count); foreach (DictionaryEntry entry in cache) { result[entry.Value] = entry.Key; } return result; } 

Then just use this custom event listener when creating the SessionFactory. I have added additional information to the corresponding NHibernate bug report: NH-3234

Answer 4

A few things to check: -

• Do you have a support field called _Portal in your domain?
• Is there also a WORD portal anywhere in your solution?
• Make a clean decision and see which DLL will remain in any BIN folder.
• Is your NHibernate configuration configured after it is created? If so, check if you are using the latest version.

NTN

Answer 5

Another idea. NHibernate lets you specify how to access your background field or its properties. For example, <property access="nosetter.pascalcase-underscore" name="Timestamp" /> will make NHibernate set the value through the _Timestamp field. Do you have such access specifiers in your mapping?