[Seaside] Prevayler

[Josh Flowers]

Avi Bryant wrote:
> On Sun, 17 Mar 2002, Josh Flowers wrote:
> 
> 
>>I'm certainly no expert, but the idea behind Prevayler intrigued me
>>enough to look into it so I'll tell you what I've discovered so far...
> 
> 
> Well, I'll tell you the issues I have with Prevayler, and maybe as you
> look into it more you can tell me if or how they're resolved.
> 
> - Commands.  Correct me if I'm wrong, but every mutation made to a
> persistent object has to be done by a Command.  I just don't see
> this working in a Seaside (or WebObjects) application - I can't hook a
> persistent object up directly to a form?
> 

I think you'd just hook a Command directly up to a form.

> - Concurrency.  How is this handled?  For recovery, each mutation has to
> be serializable in a well defined order, which means that presumably you
> need to throw a lock around your whole PrevaylerSystem - not exactly fine
> grained concurrency control.  I know, a lot of web apps use MySQL and its
> table-level locking, but...
> 
> - Transactions.  Can you abort a transaction?  Rollback?  Doesn't seem
> like it.
> 

Not in the Java version, but I plan to add undo to the commands, and 
real rollback to the system if it seems necessary.

> 
>>With WebObjects, I find that transactions get lost - I
>>find myself unable to call saveChanges() because I may be in the middle
>>of a larger transaction, and I don't want to persist it's data to the
>>database.
> 
> 
> Isn't this what nested EditingContexts are for?  

Yes, and it's the solution I end up using, but dealing with multiple 
editing contexts presents its own problems (I find it to be similar to 
multithreading - its not THAT hard to do, but when it does cause 
problems, they can be dificult to figure out).

> It sounds like you're
> saying you'd rather have no transactions at all; couldn't you get the same
> effect as Prevayler by calling saveChanges() after every mutation?
> 

No, I don't think so, commands allow multiple changes to be wrapped up 
into a single atomic operation.

> 
>>And of course it's a very new idea - it may be possible to combine it
>>with something like Aspect Oriented Programming to make it a truly
>>transparent framework.
> 

Before I go on, this last statement was very off the cuff - I'll address 
some of the issues you brought up, but what I was really trying to say 
is that Prevayler may still hold some interesting ideas that hadn't yet 
been looked into.

> 
> I don't think so - the strength (and weakness) of Prevayler seems to be
> that it forces you to funnel all mutations through a single point.
> However invisible you make the persistence mechanisms, that design
> constraint is always going to exist, and will stick out like a sore thumb.
> 

I guess Commands just seem like less of a sore thumb to me.  In the more 
traditional transactional systems I've dealt with (mostly EOF) I've been 
more bothered by the fact that I can only use persistent objects within 
a certain scope.

> Nor is AOP a panacea for transparent persistence, by the way.  To be
> useful, it really needs to be able to add advice to individual instances,
> not classes.  AOP systems for class-based languages tend not to be able to
> do this (one exception is AspectR, which gets away with it because Ruby
> has good facilities for adding behavior to individual objects).  So most
> persistence systems based around AOP techniques (eg, the Java API to
> GOODS) divide the world into persistent and non-persistent classes, which
> is pretty non-transparent.
> 

Agreed completely.  As I mentioned my original statement was very off 
the cuff.  I'm glad you mentioned AspectR though - I've been looking for 
an AOP implementation like that.

> Hmm, I hope you're not offended that you post an implementation of
> Prevayler and I immediately proceed to trash the concept.  I find object
> persistence a very interesting problem, and so am intrigued by new
> approaches, but in the case of Prevayler, I'm pretty sure the hype is
> unwarranted.  I'd be happy to be proven wrong...
> 

No need to worry, I also find object persistence intriguing and since I 
hadn't seen this sort of implementation before I thought it would be 
interesting to explore.  I've got no feelings tied up in Prevayler, and 
have enjoyed the comments.

By the way, I think some of the hype is due to the wording that 
Prevayler chose (and I carried on).  'Transparent persistence' seems to 
mislead people.  Something like 'a more natural persistence system' may 
be a better way of putting it - you can persist any object in the system 
(no need for special Array classes, etc...), and the mechanism for 
persisting the objects is part of the normal language runtime (i.e. 
Serialization for Java, RefStream for Squeak).  I also find Commands a 
more natural fit for OO programming than the more traditional 
transactional systems I've used, but that appears to just be my personal 
preference.

Thanks,

josh