From lechner@cs.uml.edu Mon Feb 20 22:30:52 2006 From: Bob Lechner Subject: Re: [Foxgui-users]Class Version#s to check serialization-Minor Update To: lechner@cs.uml.edu (Bob Lechner) Cc: sfrye@cs.uml.edu (Scot Frye), ralmonte@cs.uml.edu (Almonte) RJLRef: $PH/COOL-GEN/genclassversions060220.txt [Revised 061121] CORRECTION: This email corrects and augments my previous one (appended). I was focusing on chgen's table-row pkey version#, and I overlooked the distinction between versioned pkeys for changes to GEN application object instance values, and metadata or schema changes which affect every object's format by redefining a class as an abstract data type: (attribute names and types but not values). Jerouen serializez a version number for each object (in a particular class or table). He is probably thinking about coarse-grained versioning for a complex class or object with infrequent changes, e.g. a tree-structured graph-object (display list for one diagram). Jerouen's intended CLASS/OBJECT version# then would be a meta-attribute that could track changes to the metadata that defines a class as a data type, not changes to normal data transactions which change only attribute values. For GEN, this is equivalent to a version# attribute of a table type or class in metaschema table TT. The TA child-list of a TT declares the class's data members (name and type) but not its methods. GEN originally planned to increment version# of every single row-class object or relational table row whenever any single field changed value. But appalication data fields change too frequently, so we cannot afford such versioning. [Therefore, I plan to ignore and eventually eliminate the version# byte of each pkey. Instead, I plan to use CVS for file-level revision control, and the -log option of chgen to save change-logs between CVS revisions (e.g. during editing of a design diagram file).] [RJL061121: Later we might add a version or rev number meta-attribute to schema.sch (to table TT) for selected class or entity types, like Jerouen does. For example, table types that contain root classes for composite objects, such as a bde diagram (HG-row) or StateModel (SM-row). -RJL061121] GEN and LCP separate concerns by defining instance data members (an object's data state) and class methods (object behavior), respectively. LCP aggregates State Models for methods under an instance of an Active Class (AC). AC is the superclass of an application class from which application objects can inherit their behavior, by delegating interpretation of control flow rules to its AC. Each AC has a child_set of method-execution State Models (e.g. sub-menu methods under a GUI for that class). Each method of a class may optionally have its non-trivial control flow described by a State Transition Diagram (STD). [RJL061121: Trivial methods have a trivial one-state STD which directly calls its single State action function. This state is entered each time the method is activated. The EventInstance data members are its actual arguments. Constructing this EI object means accessing these arguments on the heap instead of the stack. Bypassing LCP to avoid this overhead (as welel as LCP interpretation) is an optimization analogous to in-lining code.] The STD defines event-driven control flow for each class method that has more than one state. State actions are written in the chosen implementation language and called from the LCP state model interpreter. States, Transitions and Actions of one STD are aggregated under one instance of the State Model (SM), and SM instances are aggregated under an Active Class (AC) superclass instance, from which they can be inherited by the sub-class. (For a GUI, the AC corresponds to a top-level menu, and its SM children correspond to the methods called from this menu.) What about metadata class methods? So far I don't see the need to have LCP-interpreted methods associated with meta-schema tables. However, the SWF text may inspire some future transformations associated with refactoring. [For example, 06f522 asgnt3 considered candidate keys whose TA-components could spread over aggregate containers or superclass counterparts, and query/update actions that navigate over candidate key specification metadata.] In conclusion, it might be practical to make rows of meta-table TT versionable, which corresponds to versioning its class definition. But I still prefer to partition classes into specialized Domains or Views (as in C++ namespaces and in the SWF text) and include a version attribute at the Domain [sub-]schema level (e.g., in a SchemaVersion (SV) parent of table TT). Note that namespace partitioning of a data model into sub-models has its own price: bridges are channels to communicate between objects across subschema boundaries, ideally without violating encapsulation of subschema internals. R Lechner Forwarded message: > From lechner@cs.uml.edu Mon Feb 20 18:14:53 2006 > From: Bob Lechner > Subject: Re: [Foxgui-users]Class Version#s to check whether serialization is valid > To: lechner@cs.uml.edu (Bob Lechner) > Date: Mon, 20 Feb 2006 18:14:52 -0500 (EST) > Cc: sfrye@cs.uml.edu (Scot Frye), ralmonte@cs.uml.edu (Almonte) > > The fox message below is about type-detection > and revision# detection during de-serialization (pr_load). > Jerouen detects the version # of each object > in a file and switches on it to re-load objects from > an external database. > [It is unclear what class instances Jerouen serializes. > I assume it is an application-specific option.] > > Jeroen does not legislate a .sch aggregate of all classes > since this would probably constrain developers too much. > He talks about one file per class, with multiple serialized > instances. > > (I can't decide from his text whether his version# > is at class or object-level. Maybe my readers can. > This is my 3rd revision after flip-flopping both ways.) > > GEN permits merging multiple class objects into one file > and pr_load must detect an object's table- or class-type > when 'de-serializing'. > > The current GEN pkey has ttabbrev plus object instance# > (table row#) plus an obsolete version#. > GEN's current pkey's version# component agrees with Jerouen's > object version#, but I want to get rid of it for simplicity. > Besides, the number of pkey version# bits is too limited > for practical use in objects that undergo rapid changes > over long life-times. > > GEN's pkey Version# can be removed because CVS can manage revisions. > However, pr_init still uses version#; after pr_init is removed. > GEN will no longer manage versioned objects, just a single > version# for an overall schema. > > To support a version# for a schema and its meta-data > [SV(schema version)---< TT(table type)---< TA(table attrib)], > each row of table SV has one version number field > for its schema revision, instead of independent > class-or-instance-specific revision#s. > (For a schema consisting of exactly one table type, > this schema rev# would be a class-level, not object-level, rev#.) > > One limitation of the planned GEN approach is that objects > cannot be checked for a correct version# at load time > (this implies an object-level version# (as Jerouen hints). > Another limitation is that ALL objects in a GEN schema > table must conform to the SAME version of that schema. > > This constrains data-conversion code generation refactorings > that maps a data file between two schema versions: > rows from the old and new versions MUST be in separate > files whose SV-field identifies the old and new schema versions. > This will continue to be a limitation of the > Domain-specialized schema approach defined below. > > > I can appreciate both choices, but I want to simplify, > not further complicate, the GEN meta-model. > However, I need to introduce namespaces for independent > Domains or Views (e.g. GEN/ERD, LCP/STD, BDE, JPsim, etc.). > For each sub -schema I can define an independent > DomainName.sch file with an independent revision number. > [Specifically , I can split GEN, BDE and LCP framework or > service domain sub-schemas from any new application domain > schema[s] while it is under development and during maintenance.] > > > But now I have to decide whether to split each Domain's data > into separate files, or merge data from multiple domains > into the same file. I prefer to allow the latter. > [E.g. COOL has at least 3 domains: GEN, LCP and BDE; > other applications are likely to have COOL support plus > more than one of their own sub-domains (SWF/DSL's)]. > > > To permit a revision # for each Domain that I merge > into one file, table type id's must consist of a > domainAbbrev + a class-specific abbrev to satisfy the primary > purpose of namespaces: This allows ttabbrev's to overlap > and be discriminated by a domain prefix: > (e.g., SISST = student type in StudInfoSys Domain, > LCPST = state in LifeCycleProto Domain) > This allows both domains to use over-lapping ST ttabbrev. > > [Note that 'Using Domain-specific Prefix' open/close braces > (like the BB...EB tree-compression technique from 91.522 OOAD) > can squeeze this prefix out of every row object . > The price of this is the ordering constraint that only same-typed > rows can be grouped at each level inside a labeled parenthesis pair.] > > R. Lechner > > Forwarded message: > > From foxgui-users-admin@lists.sourceforge.net Mon Feb 20 14:38:16 2006 > > From: Jeroen van der Zijp > > Organization: FOX Toolkit > > To: foxgui-users@lists.sourceforge.net > > Subject: Re: [Foxgui-users]how to check whether serialization is valid > > > On Monday 20 February 2006 11:00, Igor Jese wrote: > > On Tue, 14 Feb 2006 02:12:10 +0100, Jeroen van der Zijp > > wrote: > >=20 > > > On Monday 13 February 2006 18:34, Igor Jese wrote: > > >> Maybe I'm just thick, but when I want to de-serialize something (e.g. > > >> from file) how do I check whether this stream is valid? > > >> > > >> Do I have to catch the segfault? Or to put some identification data in > > >> in the file myself, in the first place... > > > > > > What I do is serialize a version number for each object; this way you can > > > load streams even for previous versions of an object. Plus you can test > > > the expected version number(s) and raise an exception when there's a > > > problem. > > > > > > The stream format itself is not "tagged" so streams can be used for any > > > kind of byte stream. > > > > > > > I think I get it. You propose to serialize the version (as e.g. FXint) of= > > > the application (or each class?) first, so you can in load() method of > > each class deserialize the version number first and then decide how to > > deserialize the rest. > > That's how I'd do it. One version number per class so it's easy to > serialize just the one class. > > - Jeroen >