Re: Prevayler - update data

Dear Karl,

Sorry I didn't mean to suggest I think it should necessarily be
exemplified, only that I use a simple "stick to prevalentSystem (when
making changes)" motto, which covers all cases.

I've made an example skeleton of how I roughly pictured the manual to
begin, although you can ignore this 100% if you wish:

<...Short intro why Prevayler is so phenomenally fantastic etc.>

The following guide shows how to make a Java object prevalent:

Let's say you have a class:

-------
class Root{
<...>
}
-------

To make it prevalent via Prevayler, type:

-------
Prevayler<Root> prevayler = PrevaylerFactory.createPrevayler(new Root());
-------

To be recoverable, any changes to your prevalent object need to be
encapsulated in Transactions:

------
class MyTransaction implements Transaction<Root>{
public void executeOn(Root prevalentSystem, Date date){
//...
}
}
------

...and performed via the given <b>prevalentSystem</b> reference.

<You could but not necessarily put an example overlooking this requirement
(i.e. a simple change made outside a Transaction) here>

When you want to execute the transaction from your program, call
Prevayler#execute:

------
prevayler.execute(new MyTransaction());
------

You can pass objects in to your transaction as follows:

------
prevayler.execute(new MyTransaction("Somebody");
------

...with a class such as:

------
class MyTransaction implements Transaction<Root>{
 String name;

public MyTransaction(String name){
this.name = name;
}

public void executeOn(Root prevalentSystem, Date date){
prevalentSystem.entities.put(this.name, new Entity(this.name));
}
}
------

However, you must bear one thing in mind: <b>your Transaction object is
serialized to disk when executed live, so anything it references will be
deserialized from scratch during recovery execution</b>. This basically
means only the <b><code>prevalentSystem</code></b> reference can be relied
upon to reference anything in your prevalent object. Here's an example
overlooking this (also known as the "baptism problem"):

<...>

etc.

On 2 November 2012 09:05, Karl Wettin <[email protected]> wrote:

>
> On Nov 1, 2012, at 9:28 PM, Naveen Chawla wrote:
>
> Although it's not part of the "baptism problem", any change to the
> prevalent object outside of any transaction is also not recoverable. So I
> like to simplify it by just thinking "stick to prevalentSystem (when making
> changes)" (while picturing the "prevalentSystem" parameter in a
> Transaction's "executeOn" method). This may or may not help.
>
>
> <
> https://github.com/karlwettin/prevayler-examples/blob/master/src/test/java/org/prevayler/examples/e105/E105Test.java
> >
>
> How's that?
>
>
> karl
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> To unsubscribe go to the end of this page:
> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>
>

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org