Re: Two step transactions?

Hiya Karl,

Here's what your example would look like without the intermediate object:

class AddBarToFoo implements ValidatingTransaction<Root>{

    long barIdentity, fooIdentity;

    void validate(Root root) throws Exception{
        if(root.bars.get(barIdentity) == null) throw new
NullPointerException("No bar with identity " + barIdentity);
        if(root.foos.get(fooIdentity) == null) throw new
NullPointerException("No foo with identity " + barIdentity);
    }

    void execute(Root root, Date date){
        root.foos.get(fooIdentity).add(root.bars.get(barIdentity));
    }
}

I think this is quicker & easier to develop and to read, & allows less
scope for unintended errors in the code, such as:

public void (Root root, Date date, Preparation preparation){
    preparation.foo = root.foos.get(fooIdentity); //won't work, because
"preparation" is not referenced by the prevalent system
}

In my opinion, these considerations outweigh any performance gain, which
may even be negative due to the intermediate object garbage collection.



On 16 November 2013 00:33, Karl Wettin <[email protected]> wrote:

>
> 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
>

------------------------------------------------------------------------------
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