Re: Two step transactions?

On Nov 15, 2013, at 10:01 AM, Naveen Chawla <[email protected]> wrote:

> I'm against this current version of your proposal because:
> 1. It's more code than just performing validation in "execute" method itself (e.g. before modifying the prevalent object).

I'm not suggesting we replace the current transaction types, I suggest we add more transaction types. Old transactions would still work just fine.

Let me reiterate the possible set downs with plain old transactions:
* If preparation/validation fails during #execute you will end up with a half baked transaction in the journal.
* If preparation/validation fails during #execute you would not know wether it was validation or transaction logic that failed unless you added quite a bit of exception handling in your transactions and around the call that executes the transaction.

It is indeed a true statement from you that it's more code with a preparation/validation step, I don't however necessarily see that as a bad thing. One according to me excellent outcome from some separation of code is that it can make it much more readable, mainly by standardizing what goes on where. I say some separation as I for instance I find it extremely hard to follow map/reduce/combine code, but in that case there are other reasons for the separation. I suppose it's worth mentioning MVC too, a solution where separation produce standardized code that easier to handle and understand at the cost of bit more code.


> 2. It appears to unnecessarily add an intermediate "validation" object.

Idea is to avoid executing the validation/preparation code twice, to only look up the persistent objects once. There is a cost involved doing that. Not sharing the preparation response would  also mean duplicating the code that looks up objects, a process that not always is as easy as looking up an object in a hash table.



		karl


------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org