Invalidating FieldManager Data

bniemyjski posted on Thursday, July 22, 2010

Hello,

I have a situation where I would like to remove or invalidate objects from the FieldManager. I'm not aware how people handle this but I am open to the best solution :).

I'm referring to a sample thats located here that will reproduce this issue. There is a case where you will have a child property that is loaded via LoadProperty:

public Diagnosi DiagnosiMemberByPrincipalDiagnosisID

        {

            get

            {

                if(!PrincipalDiagnosisID.HasValue) 

                    return null;

 

                if(!FieldManager.FieldExists(_diagnosiMemberByPrincipalDiagnosisIDProperty))

                {

....

The user may change the PrincipalDiagnosisID to point to a different record. In this case, the FieldManager Object needs to be marked as dirty so it can be reloaded. I'm thinking the best place for this would be in the Child_Update.

 

// Update foreign keys values. This code will update the values passed in from the parent only if no errors occurred after executing the query.

                if (patient != null && patient.PatientID != this.PatientID)

                {

                    LoadProperty(_patientIDProperty, patient.PatientID);

 

                    //Mark DiagnosiMemberByPrincipalDiagnosisID As Dirty via FieldManager....

                }

Thanks

-Blake

elber73 replied on Friday, August 20, 2010

Hello.

I am interested too in how people refresh the child member collection, or how to invalidate the member.

Thanks in advance.

RockfordLhotka replied on Saturday, August 21, 2010

At this time CSLA can do a rollback (CancelEdit) to a null value. It doesn't track other object reference changes for single child objects.

The simplest solution is to use a BLB child, because BLB does track reference changes (moving older ones to DeletedList for deletion), and restoring those objects in the case of a CancelEdit.

bniemyjski replied on Sunday, August 29, 2010

Hello,

Do you have an example of this for both a BLB child and a BB Child?

Thanks

-Blake Niemyjski

RockfordLhotka replied on Sunday, August 29, 2010

Example of what Blake?

A BLB does what it does - it is a self-tracking entity.

If your parent object has a child property (BLB or BB) and you change the reference it holds, that isn't subject to rollback - there's no list maintained of previous values - with the exception of null.

The behavior is very consistent.

If you want more complex undo tracking, store your child objects inside a BLB and keep the parent's reference to that BLB consistent.

rfcdejong replied on Monday, August 30, 2010

Hi Blake,

I think u want the same as i want. There is already an issue for this, but it's not in progress yet.
See my post: http://forums.lhotka.net/forums/p/7505/35738.aspx#35738

or the issue directly: http://www.lhotka.net/cslabugs/edit_bug.aspx?id=540

Greetings,
Raymond de Jong

JonnyBee replied on Monday, August 30, 2010

Hi all,

I looked into this issue for CSLA4 this spring but eventually gave up. I got some weird exceptions in the Undo mechanism when a field had been reset (ie null) and I was not able to debug/fix it within the timeframe I could use on this issue.

 

bniemyjski replied on Monday, August 30, 2010

 

Hello,

Thanks guys, that is exactly what I am trying to do. @JonnyBee, I spent 2-3 hours trying to figure this out and its a real pita... Any ETA on this feature or who wants to work on it?

Thanks

-Blake Niemyjski

 

RockfordLhotka replied on Monday, August 30, 2010

That's true, this is non-trivial.

Consider what we're talking about.

A FieldData subclass that does everything BLB does. So when a reference changes, the old value is marked for deletion and put into a DeletedList.

This means inventing a few new things:

1. Since a BLB can be a child, we need a way for a BLB to be "deleted" - and I'm not entirely sure what that means - but probably that all child objects in the BLB are marked as deleted.
2. BLB will need to support "undelete" - again I'm not sure what this means - somehow it will need to undelete all the child objects it deleted when the BLB was "deleted" - this might be easy (the existing undo behaviors may just work), or it could be quite hard.
3. A FieldData has to participate in the data portal process in a way that doesn't happen now. Somehow when a child property of an object is saved, this needs to result in child data portal calls against the current property value, and all the non-current ones in its DeletedList. So the child data portal needs to become aware of all this.
4. A FieldData has to be accessible to an object factory - because in that data portal model, you will need to write code to loop through the details of any child property and do the right thing. So object factory code for child references will become a lot more complex than today.
5. This new FieldData subclass will need to track its own edit level and participate in the EditLevelAdded type behaviors of BLB
6. BLB will need to be enhanced to have an EditLevelAdded of its own, like BB has today

I'd hoped to get this into CSLA 4, but we ran out of time.

I sure won't do this in a point release (like 4.0.x) because the changes here are major, and the odds of them having some effect on existing behaviors is quite high. So the earliest this could happen is 4.1.

bniemyjski replied on Tuesday, August 31, 2010

Hello,

I have a test case for this that I would be willing to help test this in the future.

Thanks

-Blake Niemyjski