Re: Prevayler - update data

Dear Karl,

couple of tiny little thoughts:

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.

If you are doing a manual (nice), my criteria would be as short (few words)
as humanly possible and using only code snippets, also as brief as humanly
possible, which highlight only the relevant bits, between paragraphs,
instead of linking to full code files. This may or may not be what you want
to do, but it's just my opinion.


On 1 November 2012 13:28, Karl Wettin <[email protected]> wrote:

>
> On Thu, Oct 25, 2012 at 10:14 PM, Karl Wettin <[email protected]>
> wrote:
>
> > I'm in the process of writing a bunch of example applications using
> Prevayler with escalating complexity, but so far I've only committed a
> single one. You are welcome to take a look at it
>
> I've now committed four examples that demonstrate common problems.
>
> <
> https://github.com/karlwettin/prevayler-examples/tree/master/src/test/java/org/prevayler/examples
> >
>
> Please feel free to take a look at them and let me know if there is
> something I should be more clear about, if there is something I should
> include, if there's something I've got wrong, etc. It would be most
> appreciated.
>
> I'm hoping I'll find the time to make this part of some sort of a manual
> that explains the ins and outs of Prevayler, why it works so well when it
> fits, show a bit of alternative strategies to some problems and what not.
> It would be nice if such a manual could include a couple case descriptions
> from the real world. It would be great if you who read this would not mind
> writing a few paragraphs about something you've implemented.
>
> The plan still is to create more complex examples than now available, but
> I'm also thinking about demonstrating how to set up secondary indices
> (simple solutions with maps, how to sync up with Lucene or something), when
> it make sense with alternative persistence layers for some data (e.g. it's
> silly to keep 1 000 000 users and their session data in memory at all time
> when they only visit once per month),  perhaps even a whole application
> (that would replace the no longer existing demo2) not too different from
> the "Hiberanate caveat emptor" (I'll ask to see how they feel about me
> cloning their model), etc.
>
> This will of course take some time.
>
>
>
>
>                         karl
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> To unsubscribe go to the end of this page:
> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct

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