Re: Transparent Object Persistence

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