A small improvement for CopyState and UndoChanges in Csla::Core::UndoableBase in ver 2.1

A small improvement for CopyState and UndoChanges in Csla::Core::UndoableBase in ver 2.1

Old forum URL: forums.lhotka.net/forums/t/1565.aspx


Ioannis posted on Monday, October 23, 2006

Changing the "state" local variable from HybridDictionary to a Hashtable gives better performance in these methods.

I hope the following idea is worth mentioning as well.
Could it be worthwhile to declare the [_stateStack] member variable in UndoableBase as [NonSerialized] or find a way for not sending it over the network ?

Thank you
Ioannis
 

[Story telling.]
I’m going through the code again with the 2.1 version.
Now, that I have some understanding of it, I go a bit deeper when possible.

When I saw the HybridDictionary declaration I thought that the new generic version Dictionary<String^, Object^> would be a better candidate because I thought ("There are so many fields inside BusinessBase that we may omit the internal conversion from List to Hashtable.").
It proved that BusinessBase had only six Undoable fields, and that using the generic Dictionary gave slightly worse results. Since I was still testing, I gave Hashtable a try. It performed much better.

The fact is that the "Undo" methods depend on serialization, and Hashtable serializes almost half the data than the other two containers.

ajj3085 replied on Monday, October 23, 2006

That may be a good improvment.  Just so you know though, the stateStack doesn't ever contain anything when it travels the network.  Nothing on the server side (DP methods) should be calling BeginEdit and the normal case is that edits are accepted before save is allowed to proceed.  At least that's how I remember things working.

Ioannis replied on Tuesday, October 24, 2006

ajj3085:
the normal case is that edits are accepted before save is allowed to proceed.
At least that's how I remember things working.


Well,
This is the default behavior in BusinessBase::Save which may be overridden at any time. 

For me, this is just a restriction to the usage of multi-undo functionality.
Although the framework supports, a sequence like
(fetch or create, modify, modify, save, modify, save, modify, modify, save, discard changes, discard, discard, discard, discard, save) to reset the object to its initial state,
it only allows actions like
(fetch, modify, modify, accept, accept, save {How can I get to the original now ?})

ajj3085:
Just so you know though, the stateStack doesn't ever contain anything when it travels the network

Again, even a null member variable is serialized.

I was thinking of a sequence like the following in local DataPortal.
TempStack = Obj.CloneStateStack
Obj.clearStateStack
    //Do normal dataportal processing
Obj.AttachStateStack(TempStack)

Ioannis


 

ajj3085 replied on Tuesday, October 24, 2006

Ioannis:
This is the default behavior in BusinessBase::Save which may be overridden at any time.


And as always you must take care when overriding a method and deciding not to call the base method.  When you subclass, you do have to know what the virtual method does, and if you choose not to call it, its up to you to provide similar functionality, and if you don't, you have to understand the ramifications.

Ioannis:
For me, this is just a restriction to the usage of multi-undo functionality.
Although the framework supports, a sequence like
(fetch or create, modify, modify, save, modify, save, modify, modify, save, discard changes, discard, discard, discard, discard, save) to reset the object to its initial state,
it only allows actions like
(fetch, modify, modify, accept, accept, save {How can I get to the original now ?})


That sequence doesn't make sense.  The exact details are explained in the book.  Briefly though, can you really undo a change once its saved?  What if the changes followed by the save moved the BO to a specific state which in the business world really can't (and shouldn't) be undone? 

Ioannis:
Again, even a null member variable is serialized.


I doubt that takes much space on the wire..

Ioannis:
I was thinking of a sequence like the following in local DataPortal.
TempStack = Obj.CloneStateStack
Obj.clearStateStack
    //Do normal dataportal processing
Obj.AttachStateStack(TempStack)


There's nothing stopping you from diong that now, if that's what you want.  The source is available, but you need to understand this is an edge case, and as with any framework, you need to follow certain conventions to be successful with Csla (or modify the framework to your needs).

Ioannis replied on Tuesday, October 24, 2006

I might say that the opinions we’ve stated are similar to each other or at least I see it this way.
I’d just like to remind you

ajj3085:

What if the changes followed by the save moved the BO to a specific state which in the business world really can't (and shouldn't) be undone?

What if the Business rules allow saving an object again and again?Smile [:)]
ajj3085:

Briefly though, can you really undo a change once it’s saved?

Yes, if business rules allow this. This is what happens all the time. You save a new object, you load the old object, modify the object, you save it again and again. What’s wrong if you can do this without accessing a database?
Even in notepad you can modify a text file, save it, undo to the original version and save the original again! Smile [:)]

ajj3085:

That sequence doesn't make sense. 

I just mentioned that there should be no restriction in the undo sequence. Every sequence should make sense inside an N-Level Undo implementation.

But as you said,

ajj3085:

There's nothing stopping you from doing that now, if that's what you want.  The source is available, but you need to understand this is an edge case, and as with any framework, you need to follow certain conventions to be successful with Csla (or modify the framework to your needs).

Csla is built based on some particular conventions and I completely agree with this.

Ioannis

JoeFallon1 replied on Monday, October 23, 2006

In ver 1.x I think it was a Hashtable. That is how I remember the book reading. In 2.0 I was not sure why the change was made to use a Hybrid Dictionary given the fact that it becomes a Hashtable after the 9th entry. I would think that it would almost always have more than 9 entries. So why bother? Just make it a Hashtable from the beginning. Good point about a Hashtable being almost twice as fast in your tests. I thought there was also a small point that the list index would not be maintained when the Hybrid Dictionary was converted to the Hashtable after the 9th entry. If you relied on the contents being in a certain order then your code could break. This is a subtle issue and not worth the risk of introducing the Hybrid Dictionary.

I hope Rocky decides to change it back to a pure Hashtable.

Joe

 

 

ajj3085 replied on Monday, October 23, 2006

Joe,

Just curious, why would any code rely on the state being in a certain order?  The Begin/End edit code I don't ever touch, just use.

JoeFallon1 replied on Monday, October 23, 2006

The order problem is just a general warning when dealing with Hybrid Dictionaries.

I don't have a use case for it in CSLA.

Joe

 

Copyright (c) Marimer LLC