Proxy object backing field is null though property has value

[emills-loftware]

While i was working on a bug fix i noticed that when accessing the backing field of a proxy object it can sometimes be null, while the property itself is populated with the expected value

i've found anecdotal evidence online whilst researching that this can just be a thing that happens with nhibernate but not really been able to locate a clear/official answer as to why or how to avoid in the future or if this is a bug or not.

in my testing this seems to occur when accessing the backing field via a different instance of the domain model - are there any other situations this might occur?

notice _name vs Name

here is a code sample to reproduce - relevant access happens inside LogNameForReference

internal class Program
{
    static void Main()
    {
        using (var sessionFactory = new Configuration().Configure().BuildSessionFactory())
        using (var session = sessionFactory.OpenSession())
        using (var transaction = session.BeginTransaction())
        {
            SetUpDB(session);

            var resourceA = session.Query<Resource>().First();

            resourceA.LogName();
            resourceA.LogNameForReference();

            transaction.Rollback();

            // LogName
            // =======
            // | Name  | A | √ |
            // | _name | A | √ |

            // LogNameForReference
            // ===================
            // | Name  | B | √ |
            // | _name |   | X |
        }
    }

    private static void SetUpDB(ISession session)
    {
        var sql =
@"CREATE TABLE Resource(Id nchar(36), Name nchar(1))
INSERT INTO Resource VALUES ('3B9E6E44-F281-4B6D-B661-1AEC67B653B8', 'A')
INSERT INTO Resource VALUES ('7F31A514-5742-4E18-973D-695303F130EF', 'B')

CREATE TABLE Reference(Id nchar(36), Source nchar(36), Target nchar(36))
INSERT INTO Reference VALUES ('E1774AE1-56A3-4574-A281-55AA2ABB145A', '3B9E6E44-F281-4B6D-B661-1AEC67B653B8', 
'7F31A514-5742-4E18-973D-695303F130EF')";

        session.CreateSQLQuery(sql).ExecuteUpdate();
    }
}

public class Reference
{
    public virtual Guid Id { get; set; }
    public virtual Resource Source { get; set; }
    public virtual Resource Target { get; set; }

}

public class Resource
{
    public virtual Guid Id { get; set; }

    private string _name;
    public virtual string Name
    {
        get { return _name; }
        set { _name = value; }
    }

    public virtual ISet<Reference> References { get; set; }

    public virtual void LogName()
    {
        Console.WriteLine($"LogName");
        Console.WriteLine($"=======");
        Console.WriteLine($"| Name  | {Name} | ✓ |");
        Console.WriteLine($"| _name | {_name} | ✓ |");
        Console.WriteLine("");
    }

    public virtual void LogNameForReference()
    {
        var reference = References.First();

        Console.WriteLine($"LogNameForReference");
        Console.WriteLine($"===================");
        Console.WriteLine($"| Name  | {reference.Target.Name} | ✓ |");
        Console.WriteLine($"| _name | {reference.Target._name}  | X |");
        Console.WriteLine("");
    }
}

Reference.hbm.xml

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="NHibernateFieldAccess" namespace="NHibernateFieldAccess">
	
	<class name="Reference">
		<id name="Id">
			<generator class="guid" />
		</id>

		<many-to-one name="Source" />
		<many-to-one name="Target" />
	</class>

</hibernate-mapping>

Resource.hbm.xml

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="NHibernateFieldAccess" namespace="NHibernateFieldAccess">
	
	<class name="Resource" lazy="true">
		<id name="Id">
			<generator class="guid" />
		</id>
		
		<property name="Name" access="field.camelcase-underscore" />

		<set name="References">
			<key column="Source" />
			<one-to-many class="Reference" />
		</set>
	</class>

</hibernate-mapping>

[hazzik]

or how to avoid in the future

Don’t access fields you don’t own, even if you can.

The field you’re trying to access is an unintialized field of a proxy object. The proxy has a reference to the instance object whose fields are getting initialized. This is done this way for the reason of inheritance.

The only fields you can access directly are the fields of the this object. Other objects’ fields should be accessed through properties or you need to explicitly unwrap the proxy.

[emills-loftware]

hey @hazzik thanks for the quick response!

that makes sense - i'll make the necessary changes here.

unfortunately this seems to be a pattern that appears fairly frequently in our codebase so i'll need to go through and check the other cases.

unless you're aware of an analysis/tool that could identify this kind of problem pattern?

Thanks!