I do not expect to be issuing any further updates for 1.8.
The code produced by 1.8 now uses the new exception semantics as implemented by CFLib 1.9.3110.
The IBM 3090 actually worked. My 3090 had bugs in the rules.
But my 3091 produces clean-compiling code!
I never used one, but respect for the venerable IBM 3090 is due.
In actuality, you'll find an almost-complete implementation of the ExceptionFactory architectural performance tuning of the Java exception programming model that I prefer. There are still rulesets to be converted to the new format, but the code should compile ok with a mix of old and new styles.
Update to "Copyright (c) 2012" for notices.
This highlighted the need to add a CopyrightPeriod attribute to the SchemaDefs for 1.9. I still haven't finished the PostgreSQL DELETE testing. Sorry. I've been busy with other things.
There really is no change to the core of the code factory with this release, it just incorporates an update to the BAM model for 1.9 that adds definitions for Blobs.
There was a bad assumption in the way that a decision was made at runtime whether to try to resolve a reference or not. Previously, if any of the columns involved were not null, the reference resolution was attempted.
The corrected implementation no longer attempts to resolve a reference if any of the optional columns correlate to a required target column have not been specified.
The GEL Instruction family of runtime compiler objects have been modelled.
Working on the 2.9 CFCore model, adding the compiled objects for GEL, which find their base in the GELInstruction. See 1.9 and 2.0 release notes for details.
The CFCore manufacturing wasn't properly creating the bindings for the primary key attributes of base tables, and I wasn't happy with the specifications for how to determine whether to produce a column binding or not.
The 1.9 MSSBam model has also had the DataScope, AccessSecurity, and AccessFrequency tables backported from 2.0.
S1Bam is going to replace MSSBam, so that both my proprietary and my GPL'd code bases can share common package names by just doing a little global substitution of the package path.
S1Core is similarly the replacement for CFCore.
As to what S1 stands for, you'll just have to be patient. :)
Having achieved a sufficient collection of knowledge to be able to rewrite itself using the terminology of a generic business application model, MSS Code Factory has reached its official beta release.
There are known issues and bugs that still need to be dealt with, but that should not prevent the use of this beta by early adopters.
The MssCF manufactured bindings, iterators, and references with their consolidating MssCFEngine instance are now properly constructed, populated, and ready for testing.
This means the engine can now produce an adaptation of itself tuned to storing knowledge about a new business application model and processing that knowledge into generic text files of transformed information. It's not a mere artificial intelligence, but a genetic life form with its DNA defined by the business application model.
The bindings, references and iterators are now all manufactured for 1.9, paving the way to reworking the fundamental expansion language by leveraging the model names rather than artificially created names. This will make it much easier to expand on the system in the future.
I've now automated the manufacturing of the reference implementations and the HasReference bindings. That leaves the implementation of the iterators, which don't have HasName verbs.
The MssCF layer is what binds the objects and attributes of an business application model implementation to the CFCore code manufacturing engine. The long term intent is to extend the expansion language of the definition rules by automatically binding its BL object interface to the engine.
Once this is done, the 1.9 rework of the rules can begin, where I'll be changing over from the custom coded implementation in MSSBamCF to the manufactured MSSBamMssCF implementation instead. I believe I'm producing a sufficiently rich interface in doing so to replace the custom logic with simple expansion rules in a common definition module.
Some changes will be required, for example all occurances of $ShortName$ in the rule cartridges will have to be changed to something like $AppShortName$ so I can write a rule as $switch HasShortName yes ShortName default Name$ to replace the Java logic.
For now, I've coded the SchemaMssCFBindTableCol implementation and added the SchemMssCFBindHasTableCol implementations. The "Has" bindings are only produced for optional table columns.
I wouldn't call this a "gold" release, but it's aluminum! The manufactured code for 1.9 successfully populates an empty PostgreSQL database. It does take a few minutes to do so, but it works! I'll be updating the run logs with this one -- it's a MAJOR milestone in PostgreSQL testing.
All that remains is testing of the deletes, which will be done by re-running the 1.9 test client after the initial load. A second run should recursively delete all the elements of the schema and recreate it using the loaded XML file as one big transaction.
There are probably bugs in the client code, however, so I don't expect that to work for a few hours yet.
I spent the night debugging and fixing the PostgreSQL and object layers until I finally got to the point where most of net-sourceforge-msscodefactory-1.9-mssbam-model loads into PostgreSQL. It currently dies on a TimestampDef insert, but I just don't feel like working any further right now. It's 10 AM and I've been up all night.
There are several corrections to the manufactured code with this release as I continue to debug and correct the PostgreSQL persistence. It is proceeding nicely, though. I had hoped to finish tonight, but as per usual there have just been too many subtle issues for that to happen so quickly.
I discovered a subtle runtime bug that cropped up while debugging the PostgreSQL persistence layer. I'm not sure why it didn't show up during Ram debugging -- there must be some little difference in the way I initialize and construct Ram layer objects. But it's no matter -- it's fixed now.
There was a slight error in the 1.9 MSSBam model, as I forgot to specify that the Dictionary's DictTenant relationship narrows the inherited Tenant relationship from AnyObj. Subtle runtime errors resulted when the debugger was showing the AnyObj version being set but the Dictionary entry invalid/0 on a database insert.
This major bug was preventing the majority of indexes from being properly produced for the database schema. While the application would have run, it would have been very slow without its indexes as it would have been doing table scans instead of indexed access.
I realized the due diligence review by the accounting firm probably won't start before Monday morning, so I'd best get any updates out before then. No functionality has been lost yet, so I'll refresh everything on the SourceForge distribution pages.
This build didn't need to be done, but when I realized there were SME errors I had to fix them across the board.
While getting ready to start testing the PostgreSQL interface, I discovered the ClusterUName wasn't properly unique. This hadn't caused problems earlier because a lookup wasn't being done before instantiating the default internal cluster, but the code wasn't correct.
I decided I needed a placeholder for a NumberDef to deal with Number and Decimal types of the databases. For now it will be based on a DoubleDef with some formatting specifications for the DbIOs, but some day it will use a BigNumber-cored FixedPoint implementation I'll add to CFCore.
I also add the AddNewSourceFiles and SetSourceProperties command scripts to make SubVersion maintenance a little easier while working on a project.
I applied SetSourceProperties on the whole project to get things in sync in SubVersion. Note that these utilities do not do a "svn setprops 'svn:keywords' Revision" on the .xml files, because there are a few key manufacturing rule base files where that property can NOT be set, or else the $Revision$ tag wouldn't be properly manufactured in the source code.
I didn't realize I'd changed anything that would affect the web forms, so I was surprised to find the rules enter an infinite recursion when I enabled jee support again.
This is a temporary checkin only. It at least allows you to include the JEE web form option, and produces the files and most of their cross-linking. But they are not as complete as they'd been with 1.7 producing 1.8, and that has to be fixed before I move forward with anything else. RAD prototyping is a key selling point of how I plan to present the tool.
The multiple container support has been debugged and is working in the manufactured 1.9 code base. In fact, 1.9 is now running to completion, and the resulting code has been svn diff'd to verify that only the version number strings from MSS Code Factory itself have changed.
I now have a test framework to build on for exercising PostgreSQL.
CFCore 1.9 has been created by copying the hand-written code from CFCore 1.8. MSS Code Factory 1.9 manufactured code has been compiled using the CFCore 1.9 jar files.
You will need a copy of CFCore 1.9 if you're enabling CFCore support in your models.
Thanks to the Schema and Table atom types, 1.9 weighs in at 681,886 lines of manufactured Java 6 code. In contrast, 1.8 weighs in a 526,895 lines of code, including the hand written modules that haven't been migrated to 1.9 yet.
Not bad -- an extra 154,991 lines of code with a weekend's effort.
The manufactured MSSBam 1.9 code clean compiles again. The XSDs are now produced correctly, as the new multiple container support lets you properly model objects that can be contained by any one of several containers.
Multiple container support effectively provides a "one of many" choice when defining and setting potential containers for an object. They each have to refer to a different table class which derives from the narrowed relationship's target class, and each of the container relationships you can choose from must be optional with nullable attributes so that the unchosen can be cleared to null references.
The implementation should effectively keep all the relationships properly set, no matter which setter you invoke. You should not invoke any setters you're not interested in with null values, as that will clobber everything with nulls. You should only invoke the one setter you're actually interested in with a non-null reference.
If you genuinely intend to clear all the relations to null, invoke any one of the the setters and the null will propagate.
I've added an iterator (Table.ContainerRelations) to replace the reference for the Container relationship before I can code the rules. I don't think I'll need to modify the parser or engine other than that, as the Container relationships get filtered from the main table collection of relationships, not managed seperately by modelled code.
The Components will each have to reference a distinct Container table that does not inherit from another Container relationship target table, otherwise the if-then-else code that checks the implementation of the BLObj interfaces will be unpredictable and behave wrong.
All Container relationships in such a case must reference the same narrowed relationship, so that the manufacturing rules can use the narrowed relationship without the definition changing in mid-expansion from one relationship to the next.
I need to support multiple Container relationship specifications with narrowing constraints, such that when a narrowed relationship is set, it chooses which of the n subclass container relationships to value and which to clear to null based on the class of the value being set. Using a subclass narrowing accessor should set its value, and clear others to null. Obviously this can only work if the subclass container relationships are optional, because you have to be allowed to clear some of them to null.
I've added subclasses of the atoms Schema<Atom> and Table<Atom>. The base atoms are no longer instantiable, you have to choose one of a TableAtom or SchemaAtom depending on your context, setting the Container relationship accordingly.
This has kind of backfired, as it's doubled the number of objects showing up in the XSD root document, when the goal is to get the atoms out of there. I think I have a better solution below and will be going that route.
What I really need to do is support multiple Container relationship specifications with narrowing constraints, such that when a narrowed relationship is set, it chooses which of the n subclass container relationships to value and which to clear to null based on the class of the value being set. Using a subclass narrowing accessor should set its value, and clear others to null. Obviously this can only work if the subclass container relationships are optional, because you have to be allowed to clear some of them to null.
I've changed the definition of narrowed relationships for 1.9 to RelationNarrows sub-objects of a Relation. That way more than one inherited relationship can be coordinated so that setting any of the narrowed relationships implicitly clears or sets the narrowing relationship. I may end up back-porting that change to 1.8 if I end up needing it for more than XSDs. Again I suspect this may be a red-herring change and could be undoing it; I like the multiple Container implementation concept better, and it's easier to understand the modelling necessary to make it work.
I'm at a bit of an impasse on manufacturing proper XSD specifications until I can implement and analyze the multiple Container relationships.
I've added XsdComponents as an iterator over a table. It builds a list of the instantiable subclasses referenced by all the Components relations of the table which have IsXsdComponent="true".
The rules have been updated. They seem to work ok, but there are some modelling errors being highlighted by the new functionality.
I've added the IsXsdContainer attribute to Relations, and made use of them in the schema. Only Components relationships will make use of this attribute, so if unspecified, it defaults to false. In the case of a Components relationship, it means that the referenced instantiable object hierarchy can appear as children of the object in a structured XML document.
I haven't implemented the rules to make use of it yet.
I did a significant rework of the XSD manufacturing, which required a new ColumnInComponentsRelation binding for MSS Code Factory itself.
The BuffType complex objects inherit from each other properly in the XSD and are sequenced in a top-down order rather than alphabetically. The attributes are properly specified, with primary key columns and columns which participate in a Components ownership relationship being forced optional so that they can be specified when the XML object is used as a buffer, or omitted when a structural specification is in use.
Similarly, all Components of an XML object are grouped by a generic one-optional-many relationship so that there is no artificial order imposed on the children of a given object. Specifying any restrictions on the number of elements implies specifying an artificial order with the way XSD schemas are structured, and it's far more common for order to be significant than not.
The elements of the objects aren't right in the XSD files yet -- I need a custom iterator that scans the ToTable subclasses of each Components relation of a given Table, and builds a unique sorted list of the instantiable potentially referenced tables that can be spawned by this container object.
I'll also need to add a IsXsdContainer boolean to the Relation definitions, because not all components should be expressed in XSD/XML structural documents (for example, ScopeDef contains AnyObj, but the specializations of ScopeDef are the ones that specify which specific objects they contain.)
Correct the L suffixes in Java 6 for Int64 types.
Corrected the implementation of the leadlower directive, which was incorrect in both the 1.8 Java 6 and 1.7 C#/.Net 3.5 implementations.
This version carries the rule repository as resources instead of an extracted directory. You still use the .msscfrc file in your home directory to add alternate search paths, but if the rule cartridge(s) you specify aren't found on those search paths, the default rules bundled with the factory are used.
I've also corrected the "L" suffix issue for Int64 data types.
Regression testing is complete. The core engine works.
The installation instructions have been updated for use with the new Java release. For now I'm manually building the installation package, and including all the referenced .jar files, so it weighs in at almost 9 MB.
On the bright side, it runs in less than 15% of the time of the 1.7 C#/.Net version, thanks to some rather aggressive performance tweaking in the manufactured and hand-written code. It's really not fair to compare the two, but the 1.7 C#/.Net version had been about 25% faster than 1.6 Java version.
Regression testing of the 1.7 rule base is complete. There is one minor change -- all the "long" constants don't have an "L" appended to them as they should, because of an intentional change to the design of the system. I'll correct that when I do the 1.8 rule base migration.
The Java 6 port works!
And it's fast. Where C#/.Net took about 15-20 minutes to run under Windows, it runs in under 2 minutes with all the performance tuning that's been done to the manufactured code and the engine itself. That's an 85% improvement.
There are no more misfiring rules in the code produced by 1.8, but I have not done an actual file comparison yet.
As I'm forcing the code to manufacture to a different directory than that specified in the initialization file, what I plan to do is a subversion checkout into that directory, then manufacture, and use "svn diff" to compare the results. The only difference I should see is in the MSS Code Factory build number.
The core engine technology is running under Java 6 now. The code isn't produced properly yet, though. You could say its mis-firing.
There turned out to be quite a few bugs and porting issues along the way. See subversion logs for details.
The bindings, references, and iterators have been migrated from C# to Java 6. They're properly initialized by the engine bootstrap routines, and I'm now ready to begin testing the engine runtime itself. All the code has been migrated.
The sub-object collections are no longer retained by the object instances themselves. Instead, they fetch the TableObj cache contents so that you get the most recently updated data.
I'm pretty happy with the state of the code. It's finally in a state I can be proud of, and that incorporates the vast majority of what I've learned about Java coding over the past 15 years of working on this project.
I'll be testing the deletes from the Ram database next by iterating backwards through the AnyObjTable.getAllAnyObj() results (so I unwind the load of the application model.)
After that I need to migrate the binding, reference, and iterator implementations of the MSS Code Factory from the 1.7 C#/.Net code base to 1.8 Java 6.
Then I'll have to work on the XSD generation and corresponding XML parser. I'll be relying on the base classes in CFCore for that work, so you'll only be able to use the parser code with GPLv2 compatible code unless you obtain a commercial license. As that code is going to be part of the synchronization messaging infrastructure, it forms my "hammer" to earn a living out of 15 years of work.
You can do client-server and webform applications against a PostgreSQL database with the manufactured code, but additional features will be proprietary. That's going to include the cache synchronization messaging implementation.
NarrowedRelation support has been implemented and tested. The MSSBam parser cleanup is also done.
This Subversion build number is significant because it has a fully functional 1.7 knowledge base (GenKb) and business application model (MSSBam) parsers that are populating an in-memory image of the data.