Re: Transparent Object Persistence
hakan eryargi <[email protected]> Tue, 26 Nov 2013 13:15:58 +0200
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <CAPg-4YV2Mn5X=wmjqUD8qAQP8Yx2H9POX3ohXsRRy0+NwgvK6A@mail.gmail.com> |
I'm not that guy to mavenize it but I'm very interested in that project:) I
particularly wonder how target objects are located while executing
transactions?
as you will remember from my old posts, in the past I've made a similar
persistence wrapping layer around all objects with manual written
transactions. it was working ok but all wrapper objects need to know how to
access wrapped objects from root, something like:
class BuildingP implements Building {
Building building;
Prevayler prevayler;
@Override
void upgradeBuilding(String name) {
prevayler.execute(new UpgradeBuilding(building, name));
}
static class UpgradeBuilding implements Transaction {
String userName;
int cityId;
int buildingId;
String name;
UpgradeBuilding(Building building, String name) {
this.username = building,getOwner().getName();
this.cityId = building,getCity().getId();
this.buildingId= building.getId();
this.name = name;
}
void executeOn(Game game, Date date) {
game.getUser(username).getCity(cityId).getBuilding(building).upgradeBuilding(name);
}
}
}
On Tue, Nov 26, 2013 at 1:23 AM, Klaus Wuestefeld <[email protected]> wrote:
> I have built for another project something I call the Prevayler Bubble.
>
> It provides a proxy "bubble" for your prevalentObject that intercepts all
> method calls automatically: void methods and methods marked with
> @Transaction are processed as tranactions. All objects returned by the
> bubble, including objects inside arrays and some collections are also
> returned inside their own bubbles, so you can navigate indefinitely.
>
> So the idea is you no longer have to write transaction classes.
>
> I can release that as open source if someone is willing to mavenize it for
> the prevayler project. :)
>
> See you, Klaus.
>
>
> On Mon, Nov 25, 2013 at 8:49 PM, 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
>>
>>
>
>
> --
> Valeu, Klaus.
>
>
> ------------------------------------------------------------------------------
> 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