[Prevayler-discussion] Re: Schema Evolution
Brought to you by:
jsampson,
klauswuestefeld
From: S D. <sco...@ya...> - 2004-04-30 23:53:46
|
Klaus Wuestefeld wrote: > --- 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. Yes, agreed. When thinking about schemas, it seems that there are at least two general classes of classes :-) One is what I would call native domain classes, and another I would call organizational classes. The native domain classes usually represent a single object or concept that is part of a real-life domain. Things like Person, Bank Account, Building, Document. The organizational classes are things like List, Map, Index, etc. After having done more than a few schema migrations I noticed that all but a few changes were one of the following: 1. Addition of properties to native domain objects 2. Modifying propertie values of native domain objects (this is not a schema change, rather it is simply easy to do it on snapshot reload) 3. Reshuffling of organizational classes What have other people experienced when modifying schemas? Do you find that other types of changes are also common? If these are the typical cases, I wonder if we could chain transaction versions together to avoid the "Don't Repeat Yourself" complexity problem that I think you are alluding to? |