Re: Transparent Object Persistence

what if the target is object is much deeper in hierarchy?

bank.getBranch(branchId).getCustomer(custId).getPhones(phId).setAreaCode("99");

will this be something like?

root.setAreaCodeOfPhoneOfCustomerInBranch(branchId, custId, phId, "99");

here the problem is, we are flattening a complex object graph into a single
dimension. the object graph is already there, why add another layer?



On Tue, Nov 26, 2013 at 12:49 AM, Felipe Cruz <[email protected]>wrote:

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

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