Using CSLA 3.6
Having trouble with "state" of child object getting out of sync with database equivelant.
What appears to be the problem is a child record is saved to the database but it's new and dirty flags are not set ( isNew and IsDirty remain true). This occurs becuase a second "child" being saved generated an exception. Any future attempts to save on the first child generates a new exception and an attempt to "remove" the child will not delete from the database ( becuase the object doesn't think its' saved ).
Some Specifics:
Structure:
CubeCollection
Cube
ReservedCollection
Reserved
Our application and objects may be used by multiple users. Two users open the application (objects) and if they both attempt to make identical "reservations", then second users "saving" will generate an exception.
Cloning collection then calling save from windows form.
Save calls Child_Update of Cube
Cube calls FieldManager.UpdateChildren to update "grand children"
If ReservedCollection contains 2 "Reserved", first is saved to the database successfully then second "Reserved" call to the database fails ( due to field value constraint, i.e., another user beat this one to the punch on a reservation )
It appears that due to the exception, the CSLA framework rolls back both the child objects "state" even though the first Reserved child was saved to the DB and MarkOld was called.
After handling the exception any attempt to save on the object will fail on the first "Reserved" object because it is still marked as "new" and "isdirty" even though it was saved to the DB.
All objects work properly if no exception occurs in that save and delete of a "reserved" object updates the database properly.
So, the question is, is an exception supposed to roll back all child objects "state"? Is there another way to handle this problem?
The assumption is that you are using database transactions so the changes to the object graph are either all saved, or none are saved. It sounds like you aren't using database transactions and so are allowing for a partial save - which can clearly lead to all sorts of nasty inconsistencies in the database as well as the object graph.
If this is actually intentional, and you are prepared to deal with the consequences of inconsistent data in the database, then you'll need to change the way you interact with CSLA.
No one has ever asked for something like this though, so I'm not entirely sure what to recommend. I think the answer would be to ensure you don't throw an exception on the server-side. Basically, make sure your root object's DataPortal_XYZ method catches and swallows any exception.
That'd leave the object graph on the server in sync with the partial updates of the database. And if no exception is thrown (well, if no exception escapes your DataPortal_XYZ methods) then the data portal will think the update was successful and will return the partially updated object graph.
You'll need to test this to see if it works - this is hypothetical and uncharted territory.
Copyright (c) Marimer LLC