Re: [Prevayler-discussion] Re: Schema Evolution

[Klaus W. <kla...@ya...>]

--- S Doyle <sco...@ya...> wrote:
> > So you would have things like "AddAtributeTransaction",
> > "RenameClassTransaction", "ChangeAtributeType" which would work on
> > the object schema
>
> I wonder if it would be possible either using serialization stream
> manipulation, XSL transforms

Yes. Possibly. Hard work, though.


> or with a combination of ThereCanBeOnlyOne
> and reflection.

I don't think so.

 
> However, in the spirit of keeping things simple, I wonder if they are
> even necessary, thus my hypothesis that using the Builder pattern (by
> applying TherecanBeOnlyOne to transactions instead of the domain model)
> would work well.
>
> Did you already consider and discard this approach earlier?  If so,
> what were your thoughts?  Was it strictly a matter of performance?

I had not thought of it. Well, besides performance, your system will have to contain complexity to
process all old transactions forever. That is just a downside, I think, not an absolute
showstopper.

See you, Klaus.


-------------------
> > An interesting twist to this would be to have "schema update
> > transactions", more or less like smalltalk does, amidst your regular
> > transactions.
> > 
> > So you would have things like "AddAtributeTransaction",
> > "RenameClassTransaction", "ChangeAtributeType" which would work on
> > the object schema (performing all necessary conversions too) just
> > like regular transaction work on the objects.
> > 
> > Perfectly testable, perfectly safe, perfectly manageable, perfectly
> > impossible to do in Java.  :P
> > 
> > See you, Klaus.
> > 
> > 
> > --- S Doyle <sco...@ya...> wrote:
> > > All,
> > > 
> > > I wonder if the following idea would solve the schema evolution
> > > problem, albeit in a radical fashion...
> > > 
> > > Suppose that there were no snapshots and the only record of changes
> > > to the prevalent system was the transaction log.  The object model
> > > would be constructed by replaying transactions.
> > > 
> > > The object model could be changed at any time, and the transaction
> > > classes would have to be updated to work with the new object model.
> > > 
> > > The benefits may include:
> > > - no schema evolution problem
> > > - ThereCanOnlyBeOne would make more sense when applied to
> > > transactions as opposed to the object model
> > > - less possibility of not being able to recreate state when non-ECC
> > > ram is corrupted
> > > - this approach might work better with the HttPrevayler concept
> > > 
> > > The drawbacks may include:
> > > - references to other objects within a transaction would be trickier
> > > - no performance improvement by simply reloading a snapshot
> > >   - i.e. the full log would have to be replayed
> > > - maintenance of multiple versions of transaction may be necessary
> > > 
> > > Thoughts?
> > > Scot
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> To unsubscribe go to the end of this page:
> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Do you still use a database?" -- http://www.prevayler.org



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover