Lean and clean build environment, with all old code pruned from the environment. I now have the bare minimum environment for maintaining the 2.8 release used to produce the 2.9 code, which is in turn used to produce the 2.10 project family.
There is no such thing as a TableEditObj. What was I thinking?
The customization expansion CFPlusTableEditObjImplementation has been added.
Obj.getNamedObject() should not throw exceptions if no object matching the name is found. It is perfectly reasonable to probe to check if an object exists, not knowing whether it will be found or not.
There were bugs in the narrowed relationship implementations for years and years and years and years...
The manufactured 2.9 code for MSS Code Factory works again. I sure made a mess with one little change...
The 2.9 release almost runs again after my unsubtle changes to the CFSecurity model. I think the remaining changes are in the custom SAX parser, though, so I'm submitting the current code base as a release.
There are duplicate indexes for a tenant's data so you can search for the schema models created by the specified author, or find all the component projects for a given ProjectURL.
C++ includes files; it does not import them like Java.
The CFBam model has been enhanced with Cpp/Hpp attribute members corresponding to the J(ava) members. These will subsequently have custom code added to the MSS Code Factory 2.9 implementation so that the C++ code can be enhanced with custom code the same way that the Java code is. Seeing as there are .hpp and .cpp files corresponding to each .java file in the manufactured code, a 1:1 relationship between the name groups is maintained.
The source code for MSS Code Factory 2.8 has been successfully extracted from the GitHub repositories into a clean directory tree, clean built, and repackaged as a refresh deployment.
Log4J 1.2.17 is required instead of Log4J 2.x.
The SAX RAM Loader code still had the old-style initialization of Log4J, rather than the new code for the update Log4J releases.
The code has just been rebuilt and repackaged to incorporate any updates to the code produced by the Java 8 compiler.
Additional scripts have been created for rebuilding the 2.8 code tree more easily.
The 2.9 projects are being relicensed under Apache V2, so the business application models had to be updated to reflect that fact.
Only MSS Code Factory 2.8 will remain under a Dual GPL license.
The CFCore 2.9 project model has been updated to correct a critical "spread" bug that was causing an infinite loop.
The 2.9 models have been updated to use the LGPLv2.1 and GPLv2.0 licenses.
Issue a signed release of the 2.8 projects.
Sign the git repositories with a tag using my public key.
The CFCore 2.9 model has been enhanced to support the "spread" construct in GEL.
The initial build of MSS Code Factory 2.8 is ready to test for manufacturing the 2.9 code base. I've done a quick test run of CFCore 2.9 and deleted the results without attempting a build; I need to prepare the git repositories for 2.9 first.
This is a clean build of the 2.8 migration of CFCore. Note that no one will ever actually use CFCore 2.8; it was just a stepping stone for refreshing the rules in MSS Code Factory 2.7's cfengine rule base that is used specifically for manufacturing CFCore and no other projects.
All of DB/2 LUW 10.5, MySQL 5.5, Oracle 11gR2, PostgreSQL 9.4, and SAP/Sybase 16.0 have passed their regression tests. Life is good in this universe of code.
Only Microsoft SQL Server remains untested, and I don't have a Windows box to test that database on.
The new drivers included with DB/2 LUW 10.5 correct an old bug with JDBC support for BLOBs, so the proper code has been re-enabled instead of the CLOB wrappers that used to store BLOB data as Base64-encoded text.
A side effect of the way DB/2 LUW implements unicode data is that the codes for the symbols used by the currencies take 2 or more characters to store, so the CFSecurity model had to be updated to allow up to 4 characters of data for the unit symbols for the currency objects. All projects needed to be remanufactured, rebuilt, and reinstalled as a result.
The update 10.5 JDBC drivers are included with the refreshed 2.8 projects.
It doesn't affect the functionality of the SAP/Sybase ASE scripts, but there were some minor glitches in crdb_dbschemaname.bash that was littering the script directory with files that didn't need to be there. That has been cleaned up.
With the update to the latest version of SAP/Sybase ASE, an assumption in the CFSecurity 2.8 model was corrected, so all of the projects needed to be rebuilt and repackaged (ASE treats null as equal to null, uncovering a unique index that should logically allow duplicates, though the last rounds of testing with ASE a year or so ago had not uncovered this oversight.)
See the MSS Code Factory 2.7.13635 notes for further details about the results and changes made for the SAP/Sybase ASE testing.
The SAP/Sybase ASE jconn4.jar has been updated to the latest 16.0 patch release.
SAP/Sybase ASE scripts install without errors now, too. The easiest way to peruse the log file for errors is to do 'grep Msg *.log -A 5 | more' and just ignore the 'Msg 2007' warnings caused by references to stored procedures that haven't been defined yet; they'll get defined and the runtime will be ok.
All the databases that can be test-installed have been. I don't have a Microsoft SQL Server instance. I looked into using their developer Azure databases on the cloud services, but they presume you have a Microsoft client to upload the schema and don't let you install a schema from scripts in a shell.
The revision checks in the sp_delete_table stored procedures have been removed, propagating a fix I had made some time ago to the PostgreSQL and MySQL database scripts.
Ignore this release.
The database schema installation scripts for all of the 2.8 models now install without errors for DB/2 LUW Express-C, MySQL, Oracle XE, and PostgreSQL.
CFLib 2.7.13625 reduces CFLibBigDecimal.MAX_DIGITS to 31 in compliance with DB/2 LUW's restrictions. The CFBam 2.8 model now specifies Digits="31" instead of Digits="38" as a result (previously 38 was the most restrictive limit, imposed by Oracle XE.)
The latest custom code from CFBam 2.7 has also been ported forward.
Serious defects in the database creation scripts were corrected by changes to the 2.8 models and the 2.7 rule base. Those defects were discovered while installing the database schemas for Oracle XE. All of the databases now install as cleanly as possible.
The changes made to Oracle's scripts have also been made to those of the other databases, as all of the databases share a lot of common logic and structure.
You will see warnings/errors in the Oracle database installation log about "invalid" objects for CFBam 2.8 and CFFreeSwitch 2.8. Those objects have compiled clean, but they are stale because the objects they depend on have been updated since they were compiled. Oracle should resolve the issue at runtime.
The other databases install with no errors or warnings.
Tables which specify PageData="true" need to specify descending indexes so the future data paging code can function properly. This also affects the sorting of data in the GUI.
CFLib 2.7.13616 reduces CFLibBigDecimal.MAX_DIGITS to 38 in compliance with Oracle's restrictions. The CFBam 2.8 model now specified Digits="38" instead of Digits="65" as a result (previously 65 was the most restrictive limit, imposed by MySQL.) CFDbTest 2.8 was already compliant with Oracle, specifying a maximum of 20 digits for its Number types.
The migrated editor output formatter code was referencing mssbam-2.7.xsd instead of mssbam-2.8.xsd.
Note that you should be using the CFBam 2.7 Editor that is included with the main MSS Code Factory 2.7 distribution for editing your models, not the 2.8 release. The 2.8 release is development code, not production, and shouldn't be used with models you intend to manufacture.
The database names for the relationships were lost in the models and had to be restored.
The code has all been remanufactured by MSS Code Factory 2.7.13608-SP2 Service Pack 2, rebuilt, and repackaged. The latest version of the custom code for CFBam 2.7 has been ported to CFBam 2.8.
The qualified object names have been reworked because they weren't being calculated unless they were defined by a base class, which is incorrect behaviour. This was showing up as fully qualified names from the tenant on down in the CFBam 2.7 Editor where I was expecting to see names qualified by the BaseProject or by the SchemaDef.
The getEffJavaFXFocus() gets the focus of the form, and if it is being edited, returns the edit object, otherwise returning the focus. This is important for populating choice lists, as when you are adding a new object, only the edited version has its containership links properly established for resolving lookups.
When posting optional string/text fields in the AttrPanes, an empty field is now interpreted as a null. Inversely, if a field editor returns null, a required string/text field is now set to an empty string.
Only none, Cluster, or Tenant can be chosen as the dispensing table for an id generator.
When emitting the initializers for the string and text types, it is necessary to force empty strings instead of nulls the same as in the editor forms, otherwise invalid code gets produced by the factory when the saved model is loaded.
UUID generators can't really be dispensed by tables -- they're programmatic.
Ported the latest 2.7 custom and editor code forward.
In addition to porting the CFBam 2.7 code forward, the production of the installer for the CFBam 2.8 Editor has been enabled.
You could, in theory, copy-paste and modify the editor to connect to a XMsg server with some changes to support the CFSecurity/CFInternet custom tabs similar to other custom clients, but I wouldn't recommend that. Too much of the behaviour of the editor presumes that it is dealing with RAM storage, and therefore ignores atomic consistency. You would have to turn a lot of the editor functionality into ServerProcs to make it safe to run against a database. But still, I am sure someone will try to make it go regardless of the risks.
Plus there is the minor fact that the editor isn't set up to probe a database for schema reference packages at all, and even if it was, you'd have a serious problem with changing any of the referenced packages after another model referenced them, because you would get integrity violation errors up the wazoo. Still, I can see someone taking the effort of reloading entire databases from the model files on a periodic basis so that they could have a shared storage system for multiple developers/analysts to work on a model.
Hey, I'm not going to stop you -- but I'm not going to try to do it myself. It is just too daunting a task to deal with. I'm content to edit files instead.
There were some design flaws in the CFAcc(ounting), CFAsterisk, and CFBam models detected by the new 2.7 model validator. These have been corrected, the 2.8 projects remanufactured, built, and repackaged with the corrections.
The model validator has not been ported forward to CFBam 2.8; I won't do that until after Service Pack 1 is released.
The DataScope, VAccFreq, EAccFreq, VAccSec, and EAccSec attributes have been stripped from the CFBam 2.8 model. The EnumCol table has also been removed, as you have to define Enum types as Schema types that are shared, not locally to a table.
The updated code to support those changes has been forward-ported from CFBam 2.7 to CFBam 2.8. CFBam 2.8 now has a full copy of the CFBam Editor as a result, though there is no 2.8 factory at this time (and likely never will be.)
The new versions of the libraries/jars produce beeps when errors are caught and logged, so that you get some audible feedback when a manufacturing run is failing.
The CFBam 2.8 model now has labels on most of the columns that don't participate in relationships, and on the relationships themselves, so it looks much better than it used to, even with default manufactured code for JavaFX.
The formatting of the attribute and list panes has been tidied up. The code worked, but it was ugly to look at. I hate ugly code.
It should have been a trivial thing to implement, but it was not.
CFLib 2.7.13526 tries to use the most basic of Java audio support to play an alert.wav file, but no matter what approach I use, it will not play under Debian Linux. I give up. But I won't remove the code, in hopes that it might work for Windows and Mac users. At least it doesn't error-out.
The HTTP clients now accept a trace/notrace argument indicating whether exceptions should be logged to the system console. The default is to not log exceptions.
The Prev/Next chain links are now filtered out from the AttrPane displays, seeing as all they did was clutter up the user interface and provide yet another point of entry that would have to be customized to prevent the user from editing data they shouldn't.
A subset of the DelDeps I used to have in the 2.8 model have been restored.
You will not be able to delete any finalized data, were causing problems, but normally you don't want people deleting historical data from an accounting system anyhow.
Fixes made to other issues have made it possible to remove the CFBam.Scope.Cont container relationship, which corrects the missing variable declaration problems in the database creation scripts.
Oh happy day! This was a brain fart I am GLAD I woke up with! :D
All of the database creation scripts for MySql and PostgreSQL have been tested, which uncovered some issues for MySql support. MySql only supports numbers with a maximum of 65 digits, so the maximum used in all of the models for 2.7 and 2.6 have been reduced from 100 to 65, and the support limitation set by the CFLib implementations has also been reduced accordingly.
Issues with the CFAcc model were uncovered as a result of the MySql testing. With the corrections that have been applied, you won't be able to delete data from a RAM database for CFAcc. But as that application is intended to run against an RDBMS, that is a non-issue.
A Prev/Next Chain has been added to the SchemaRef object to keep the model in sync with 2.7.
MSS Code Factory 2.7.13491 incorporates a complete set of delete routines for the RAM database, and the CFBam 2.8 model has been updated with the latest version of the 2.7 design.
Enjoy! I know I'm pleased with myself. :)
I've decided I'm not going to fix that bug in the rule base, because there is too great a chance of breaking database code that I can't test. It is just some undefined variables in 4 stored procedure scripts for each CFBam database instance. As I never intended to store CFBam in a database, I don't care about the bug all that much. Anyone crazy enough to install that beast to a database server can fix those four declarations by hand.
There were major model changes to CFBam with this release. The preparation has been laid for adding moveup/movedown ordering to the DelDeps and ClearDeps, but the stored procedures for those four routines are invalid right now. I know what I need to do to fix them, but I'm too tired to tackle it right now so I'm shipping the code as-is.
The new code does clean compile, though. I haven't tested it yet, though I don't expect any problems. (What programmer ever expects problems? We all have egos the size of Jupiter.)
The implementation of forgetRelationships() has been backed out, and the RAM implementation of moveBuffUp()/moveBuffDown() has been applied.
The Java layers have been remanufactured and rebuilt to ensure that the stale relationship bug doesn't crop up in the field. It hasn't been a problem for the engine itself because the only updates done during a model or rule loading process is to establish new relationships for some that had formerly been null during the initial insert to the RAM database.
That isn't true when you are editing data -- stale relationships are much more likely to become a problem, as the previously established relationships won't reflect the new data values after an update or, more importantly, if data is refreshed that was changed by a different user running an application against the database.
In other words, while I haven't seen it crop up, this was a MAJOR multi-user bug.
CFLib 2.7.13466 corrects defects in the formatting of large numbers for XML files and messages.
As CFLib 2.7.13462 had been released and updates should be shipped, I took this time as an opportunity to remanufacture the 2.8 projects to apply the low-priority changes that had been made to the rules and to the models.
The custom code that used to be in the factory itself has been ported forward to 2.8.
Constructing a TopProject in the Hierarchy browser was failing if you tried to attach a TopProject to a TopDomain, which is allowed by the model (in fact, it is probably the most common way of naming a project.)
The initial code snapshot has been built from the code manufactured by MSS Code Factory 2.7.13427.