CustomFieldsManager error

[jguengerich]

I couldn't get the ExtendedFields collection to work (see here:viewtopic.php?f=65&t=18937), so I thought I'd use CustomFieldsManager instead. I'm using R12 SR1.
When I try to create a CustomFieldsManager for some orders like this:

Code: Select all

CustomFieldsManager orderCustFieldMgr = new CustomFieldsManager(oneOrder);

I get an "System.NullReferenceException: Object reference not set to an instance of an object" error. I have traced it to the following line in the initilizer in CustomFieldsManager.cs:

Code: Select all

_tableName = AbleContext.Current.DatabaseFactory.Configuration
    .GetClassMapping(_entity.GetType())
    .RootTable
    .Name;

For the orders that don't give the error, _entity.GetType() is returning {Name = "Order" FullName = "CommerceBuilder.Orders.Order"}.
For the orders that give the error, _entity.GetType() is returning {Name = "OrderProxy" FullName = "OrderProxy"}.
This causes AbleContext.Current.DatabaseFactory.Configuration.GetClassMapping() to return null, causing the NullReferenceException when it tries to access .RootTable.

Any idea why this is happening or how to fix it? The orders that exhibit this behavior are credit card orders that have been authorized, but not captured yet, if that helps.

[mazhar]

I just updated your other thread viewtopic.php?f=65&t=18937

[jguengerich]

I can use the workaround for the ExtendedFields bug in the other thread, but isn't this a different bug that should be fixed also? I don't understand how GetType() can return one result for some orders and a different result for other orders. However, if this is expected, then the CustomFieldsManager init code needs to handle this properly.

[mazhar]

Actually as of this point CustomFieldsManager is not intended to be used separately hence its. Even if you get it to initialize it won't be able to save the information since it only allows Entity classes in CommerceBuilder to save the fields. In your case how are you loading oneOrder object? I wonder if somehow its a hibernate lazy loaded proxy instance.

[jguengerich]

I am doing this (with 'using NHibernate.Linq'):

Code: Select all

            heldOrders = from order in session.Query<Order>()
                                    where order.PaymentStatusId < (int)OrderPaymentStatus.Paid && order.OrderStatus.OrderBy < invoicedStatus.OrderBy && order.OrderDate < DateTime.Now.AddDays(-5)
                                    select order;  // invoicedStatus is set in code above here to the OrderStatus I have called "Invoiced"
            foreach (Order oneOrder in heldOrders)
            {
                // do stuff
            }

But, as I mentioned, within that foreach loop, some of the orders are Order (CommerceBuilder.Orders.Order) and some are OrderProxy.
I'm guessing creating an NHibernate Criteria and using OrderDataSource.LoadForCriteria() would work, instead of using LINQ? The LINQ is so much easier to code and read though.
Anyway, if CustomFieldsManager is not meant to be used separately, I will try the ExtendedFields workaround.
I'm curious, you said:

Actually as of this point CustomFieldsManager is not intended to be used separately hence its.

What word or words are missing at the end of that sentence?

[mazhar]

I was trying to say that CustomFieldsManager wasn't intended to be used separately. If you have source code you will notice that Save method is internal on CustomFieldsManager and can only be invoked from inside CommerceBuilder entity classes. BTW you can unproxyfy the proxified order instances and then try initializing the CustomFieldsManager. It would work as read only manager since you won't be able to call save due to privacy level.

Code: Select all

AbleContext.Current.Database.GetSession()
                .GetSessionImplementation()
                .PersistenceContext
                .Unproxy(oneOrder)

[jguengerich]

Now that you mention it, I did notice that CustomFieldManager's Save was marked internal, but since I was getting this error I was trying to figure this out first. Thanks for all the information, I'll stick with the ExtendedFields workaround (assuming it works consistently - still haven't had time to test it).