Re: Work on Release 2.6: Maven Archetype and Tutorial Examples

IMOWS = In My Opinion We Should

> I renamed Entity to Person in e101, but left it as Entity in all other
> packages.

IMOWS do that in all packages.


> Also switched package of e103 and e104 so all non deterministic stuff "came
> in order".

Cool.


> I rephrased it like this:
>
> Transactions shouldn't contain actual business objects, instead they should
> contain information about the business object so they can be found in the
> prevalent system root using a query, a unique identity for example.

Cool.


> Klaus Wuestefeld: "an aggregate of an business object to another business
> object" is too abstract. Lets choose a metaphor and run with it: "a pilot to
> a car", "a pet to the petstore", for example.
>
> I didn't get around to do this. I actually like the abstractness of
> "aggregate", but I'll try to come up with something better that's easy
> enough to demonstrate with as few lines of code as possible.

"Person has Pets" is an idea.


> Klaus Wuestefeld: Please, lets change the wording from "baptism problem" to
> "initiation problem". It's  more religion-neutral.
> Klaus Wuestefeld: user is baptised -> user is initiated
>
> Done. There's a bit of references to baptism all over the repo, we should be
> consistent and change it all over.

Agreed.


> Klaus Wuestefeld: 10) finally: please delete E105. It is too alarming. In
> the end, it is the same as E101: You have to use transactions. Simply add a
> line of text to the description of E101: "If you change business objects
> directly without using transactions, those changes will not be persistent.
> You could, in theory, take a snapshot after every change but that is much
> slower."
>
> I argue raison d'etre for e105. It clearly demonstrate what happens if you
> attempt to do changes to the prevalent system outside of transactions.

I think that is unnecessary.


> And the third test within it that makes changes outside of transactions and
> then make a snapshot is a feature I've used it a lot when bulk importing
> information to initialize a root, for example when importing data from a
> previous version of my software after major refactoring. Perhaps a bit more
> text in there to explain this makes sense though.

The test can demo only the valid cenario and be called "bulkImport".
The text: "You can make changes to your objects directly, without
using transactions, only if no other threads are reading the objects
and you will save your changes using a snapshot. This is used for bulk
import of a legacy system, for example."


> Klaus Wuestefeld: 11) Lets delete Prevayler demo1 (prime numbers) if it
> still exists.
>
> It does indeed still exist. I did not yet remove it.

IMOWS remove it.


> Demo2 does not exist, it was hard coupled to the javamatch which was removed
> back in 2.3 or so, i.e.  "git checkout v2.3" would bring it back if you want
> to take a look. (use "git tag" to list all tags)
>
> I do however like the bank as an example domain and I could re-implement it.
> How about we draw a class diagram first so we all agree on the design?

IMOWS simply bring back the bank demo.

I was not aware the bank demo was going to be deleted entirely. That
was a big loss. :( The coupling to JavaMatch was minimal.

Klaus

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org