Re: Transparent Object Persistence

The Facade idea is definetely not bad, but I think regarding the
possibilities it's a bit unsufficient. The problem IMHO is, Prevayler
itself honors object oriented design but the Facade idea -in contrast-
utilizes service oriented design and introduces an uncessary layer for
persistence.

I respectfully disagree.. Facades is a OO pattern and Services is Service
is an Architectural pattern (
http://martinfowler.com/eaaCatalog/serviceLayer.htm), that can be
implemented in OO as a Facade, and they introduce a *necessary* persistence
layer so people don't object.save() inside controllers coupling, for
instance, Controllers and Models.

IMHO, set*() and save*() are poor idioms to represent business
transactions.. OTOH facade/services are good idioms to represent business
transactions and you can also unit test them, which I found to very handy.

So, why not change:

root.children.get(id).setSomeProperty(x);

To:

root.setSomePropertyOnChild(id, x);

regards,









2013/11/25 Naveen Chawla <[email protected]>

> Hi Hakan, are you sure that annotations would be necessary? I wrote a
> compact suggestion that doesn't require annotations a while back ("Future
> Prevayler").
>
> If bytecode manipulation is used, then surely field accesses can be
> intercepted, and perhaps even object locks can be acquired via bytecode
> automatically during accesses, allowing you to do something like:
>
> final MyObject prevalentObject = Prevayler.<MyObject>connect("name");
>
> /*or ("name", new MyObject(x, y, z)) if there's no default constructor or
> you wanted to set a special default state.*/
>
> on start up, upon which "prevalentObject" would become the object
> recovered from the snapshot and/or journal if it exists, and then all
> subsequent access to "prevalentObject" in your code would be synchronized
> over (and journalled in the case of changes) automatically.
>
> i.e. nothing else necessary.
>
> Am I wrong that this is possible? I haven't done bytecode manipulation
> before but it definitely says in AspectJ
> http://theholyjava.wordpress.com/tag/aspectj/ that it can intercept field
> access, and acquiring locks over objects is a simple bytecode instruction.
>
>
> On 24 November 2013 21:32, hakan eryargi <[email protected]> wrote:
>
>> come on, AFAIK object databases does not store POJO's. I'm talking about
>> persisting POJO's transparently here.
>>
>> for tx boundaries, it's determined by methods with @Writer (@Transaction
>> is better I suppose) annotations which are in classes that can be accessed
>> starting from Root.
>> On Nov 24, 2013 10:31 PM, "Justin T. Sampson" <[email protected]> wrote:
>>
>>> That's not revolutionary, that's an object-oriented database. :) Not a
>>> bad idea, but a different idea than Prevayler.
>>>
>>> The essential issue is how to demarcate transaction boundaries. It's not
>>> sufficient for individual setter calls to be their own transactions, so
>>> you've gotta have some higher-level coordination.
>>>
>>> Prevayler itself does this using a variant of the Command Object design
>>> pattern, where each command object encapsulates a single transaction. The
>>> Facade design pattern is the most obvious alternative, where every method
>>> declared on the facade demarcates a transaction.
>>>
>>> Both of those options are legitimate object-oriented design patterns. :)
>>>
>>> Domain-Driven Design offers another way to think of transactional
>>> boundaries: The Aggregate design pattern is intended precisely to demarcate
>>> transactional boundaries in a domain model. So that might be a fruitful
>>> area of study if you're concerned about the design side of things.
>>> On Nov 24, 2013 10:10 AM, "hakan eryargi" <[email protected]>
>>> wrote:
>>>
>>>> Justin, thanks for the pointer:) The Facade idea is definetely not bad,
>>>> but I think regarding the possibilities it's a bit unsufficient. The
>>>> problem IMHO is, Prevayler itself honors object oriented design but the
>>>> Facade idea -in contrast- utilizes service oriented design and introduces
>>>> an uncessary layer for persistence.
>>>>
>>>> Wouldnt it be great if objects are transparently persisted?
>>>>
>>>> Root root = Persister.create(Root.class)
>>>>
>>>> class Root implements Serializable {
>>>>    @Writer
>>>>    void setSomeProperty(X x) {}
>>>>
>>>>    @Writer
>>>>    void setSomeOtherProperty(Y y) {}
>>>>
>>>>    @Reader
>>>>    X getSomeProperty() {}
>>>> }
>>>>
>>>>
>>>> For top level class (the root of object graph) I suppose that's a piece
>>>> of cake to implement with aspects or bytecode enhancement.
>>>>
>>>> For child classes, there is a difficulty of accesing target object
>>>> while executing the transaction. But I believe this can be solved to some
>>>> degree by replacing collections with wrapper collections.
>>>>
>>>> For example a typical pattern is:
>>>>
>>>> class Root {
>>>>    Map<Integer, Child> children;
>>>>
>>>>    @Writer
>>>>    void saveChild(Child c) {
>>>>        children.put(c.id, c);
>>>>    }
>>>>
>>>>     @Reader
>>>>    Child getChild(int id) {
>>>>       return children.get(id);
>>>>    }
>>>> }
>>>>
>>>>  class Child {
>>>>    @Key
>>>>    int id;
>>>>
>>>>    @Writer
>>>>    void setSomeProperty(X x) {}
>>>> }
>>>>
>>>> Now, If we replace children map with a special wrapper map, at the
>>>> point of insertion, we can store the access path to the child in a special
>>>> bytecode enhanced field of Child. Something like: parentClass: Root,
>>>> id=idValue. So the transaction will be like (or the reflective equivalent) :
>>>>
>>>> root.children.get(id).setSomeProperty(x);
>>>>
>>>> If the Child has no filled in path field than it means it's not
>>>> attached to Root and write action should not be encapsulated in a
>>>> transaction. If it's later inserted into object graph, then it will be
>>>> written as it's (its properties are set etc) in a transaction.
>>>>
>>>> For deeper classes in hierarchy it's more complicated but I guess same
>>>> principle can be applied. Just store the parent's key value in
>>>> path-to-object field, and when write method is executing, traverse up in
>>>> the hierarchy and check if Root is accesible. If so, object can be accessed
>>>> in the same way:
>>>>
>>>> root.children.get(id).someOtherChilren.get(otherId)...
>>>> setSomeProperty(x);
>>>>
>>>> Some annotations may also help this process.
>>>>
>>>> @Path("Root/chilren/{id}/someOtherChildren/{otherId}")
>>>> class SomeChild {
>>>> }
>>>>
>>>> Of course this is much more complicated then I wrote here and several
>>>> unforseen problems may occur (for example arrays can not be handled this
>>>> way) but I belive it may worth the effort.
>>>>
>>>>  Combine this with Spring's dependency injection:
>>>>
>>>> <prevayler:component-scan base-package="some.package" />
>>>>
>>>> package some.package;
>>>> @Root // a persisted object graph root
>>>> class Root {
>>>> }
>>>>
>>>> Root can be injected:
>>>>
>>>> class SomeBean {
>>>>    @Autowired
>>>>    Root root;
>>>> }
>>>>
>>>> And maybe even child classes can be injected:
>>>>
>>>> class SomeOtherBean {
>>>>    @Autowired
>>>>    @PathToChild("/Root/42") // 42 is id of child
>>>>    Child child;
>>>> }
>>>>
>>>> And other beans can be injected into persisted objects too
>>>>
>>>> class Root  {
>>>>     @Autowired
>>>>     transient EmailService emailService;
>>>> }
>>>>
>>>> Wouldn't that be revolutionary? What do you think?
>>>>
>>>> *r a f t*
>>>>
>>>>
>>>> On Fri, Nov 22, 2013 at 8:40 AM, Justin T. Sampson <[email protected]>wrote:
>>>>
>>>>> Yes, Prevayler uses synchronized(prevalentSystem){...} internally for
>>>>> both queries and transactions (plus additional synchronization for
>>>>> transactions to get the journal sequencing right).
>>>>>
>>>>> A few people have played with the latter idea. There's even a
>>>>> proof-of-concept included with Prevayler, in the extras/facade module.
>>>>>
>>>>>
>>>>>
>>>>>  On Thu, Nov 21, 2013 at 11:20 AM, hakan eryargi <
>>>>> [email protected]> wrote:
>>>>>
>>>>>>  is it enough to sync on root object for reads? writing a query
>>>>>> class for each read is really verbose.
>>>>>>
>>>>>> indeed even writing tx classes for writes is also verbose. a future
>>>>>> improvement may be using magic @annotations very much like spring's.
>>>>>>
>>>>>> r a f t
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>> innovation.
>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>> game-changing
>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>> up now.
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Shape the Mobile Experience: Free Subscription
>>>>> Software experts and developers: Be at the forefront of tech
>>>>> innovation.
>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>> game-changing
>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>> up now.
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&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
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Shape the Mobile Experience: Free Subscription
>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>> game-changing
>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>> now.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&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
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Shape the Mobile Experience: Free Subscription
>>> Software experts and developers: Be at the forefront of tech innovation.
>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>> now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&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
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up
>> now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&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
>>
>>
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&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
>
>


-- 
Felipe Cruz
http://about.me/felipecruz

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&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