Re: Transparent Object Persistence

Some 10 years ago I was using the object database XL2. If I get you right then it does just that what you describe. It's probably also 10 years ago too since someone worked on XL2, but when I used it it felt as stable as anything else. Can't find a good link to the code for you. Used to be xl2.net. I'm sure it's out there, start by searching for "xl2 odb".

		karl

On Nov 24, 2013, at 10:32 PM, 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