Sign the git repository with a tag using my public key.
The cfengine rule base has been refreshed and used to manufacture CFCore 2.8.
This is the first step towards a 2.9 release that I can modify with the planned "spread" statement for the GEL engine implemented by CFCore.
Just for something to do, I did a confirmation test of a fix I had put in for a DB/2 LUW issue, and verified that the fix worked. With that done, I think MSS Code Factory 2.7 should remain quite stable until I decide to work on the "spread" statement for the GEL syntax, should I ever choose to do so.
But to be honest, working on that is more appealing than working on CFAccounting itself, so I might get started on that in the relatively near future as a 2.9 branch of MSS Code Factory. I don't want to make major changes to 2.7's GEL engine; I'd rather do that as an incremental full release of the tool.
The only change Oracle required was making the CFInternet MimeType FileTypes attribute nullable, because Oracle treats empty strings as nulls.
Only Microsoft SQL Server remains untested, and I don't have a Windows box to test that database on.
There were no changes required by MySQL 5.5. It passed the CFDbTest 2.8 regression tests without changes to the code. All I had to do was set up the JNDI connection resource for Tomcat 8.0.
After giving my approach to implementing data paging a lot of thought, I've realized that what I want to do just can't be done with MSS Code Factory as it exists today. In order to be able to specify rules that would implement a multi-part key "less than" comparison of the last record's primary key, I'd need some sort of construct other than my iterators for accessing the index columns.
A multi-part key has to consider cases where columns n, n+1, and n+2 are equal, but n+3 is less than the last record's value. Also valid are cases where n and n+1 are equal, n+2 is less than, and n+3 is ignored. Then there is the case where n is equal, n+1 is less than, and n+2 and n+3 are ignored. Finally, there is the case where n is less than and n+1, n+2, and n+3 are ignored.
That type of branching logic has to be made valid for any number of columns in the primary key, but I can't even implement a restricted set such as "up to three columns" with the way the MSS Code Factory engine and GEL syntax are coded right now.
I do have some ideas now about how I could go about coding it if I wanted to go to that much effort to support a special-case feature.
What I'd have to do is define a GEL statement I've decided to call "spread". Spread is similar to an iterator, but what it does is takes the iterator that it evaluates, and uses it to build up a series of lists of n, n-1, n-2 and so on elements.
It would have the additional expansion tag "between" to be emitted between evaluations of those lists in order of decreasing length (so a nested iteration of iterators.)
Each of those lists would be evaluated using the same expansion tags as an iterator.
So you'd have something like this:
$reference PrimaryIndexKey spread Columns ( between emitOr before emitLParen after emitRParen each emitColumnEquals last emitColumnLessThan )$
But that would produce the logic needed to properly evaluate a generic multi-part key. grin emoticon
Maybe some day I'll be bored enough to implement it. But if I do, I think I'd have to do it as a 2.9 release of code, because it changes foundational behaviour of MSS Code Factory itself. So it is a long way off if it ever happens at all.
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.
DB/2 LUW does support UTF-8 character data, but it has to be enabled at database creation and is not the default mode. See the updated 2.7 documentation for details.
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 need 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 regression tests, but there were some minor glitches in crdb_dbschemaname.bash that were littering the sybase script directory with files that didn't need to be there. That has been cleaned up.
I figured I may as well re-issue the release and packaging to clean it up now rather than having to do a full release again even if the regression tests for the other databases goes ok. After all, I just started the uploads, so better to spend 20 minutes now than 7 hours later.
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.)
This was the first time JNDI connections were exercised for ASE, so changes were made to the code to allow for the way the JNDI string gets parsed by the 16.0 jconn4 driver.
It seems the 16.0 version of the jconn4 driver also corrects a bug in the driver that was causing a mismatch between the number of arguments specified by "?" in dynamic SQL and the number of arguments in the statement's buffer manager in the driver. Happily, this means code that should have worked all along now works properly.
Next I'll be working on the regression tests for DB/2 LUW, MySQL, and Oracle in no particular order. I'll see where my whims take me.
I should probably have done this testing before releasing Service Pack 4, but I am only one guy and there is always more work to be done and always another Service Pack in the future as I slog my way through that work and fix more code.
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.
I've only tested CFBam 2.8 and CFAccounting 1.1 for ASE because CFBam 2.8 exercises the full suite of data types and manufacturing features. Even CFDbTest 2.8 doesn't exercise as much code as CFBam 2.8 does.
I had removed the revision checks from the PostgreSQL sp_delete_table code, so I've propagated that change to the other databases because clearly my past debugging had found it to be a problem.
I don't have a Microsoft SQL Server instance, so those schema creation scripts have not been tested. 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.
DB/2 LUW, MySQL, Oracle, PostgreSQL, and SAP/Sybase ASE have all been tested, though.
To paraphrase Meg Ryan in "When Harry Met Sally":
"Yes, yes, Yes, YES, OH GOD, YES!!!!"
I have a working SAP/Sybase ASE server installed on my Debian "Jessie" amd64 Linux box.
Stand by for more testing and a possible update...
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.
Issues uncovered during the DB/2 LUW testing resulted in changes to the rules for Oracle that eliminated the errors it was previously reporting.
MySQL now installs CFBam 2.8 without complaints as well, as those same changes were applied to its rules as well.
Microsoft SQL Server and SAP/Sybase ASE cannot be tested because I do not have a Windows box any more, but the changes made to the other databases were applied to their rule bases as well, so hopefully they will install clean.
I uncovered further issues with the database schema creation scripts during my DB/2 LUW testing, so I have pulled Service Pack 3 and the 2.8 projects from distribution until I am done testing the DB/2 LUW Express schema installations of the 2.8 projects and CFAccounting 1.1.
So far I've done clean installations of CFAccounting 1.1, CFBam 2.8, and am waiting for the scripts for CFDbTest 2.8 to run. After that, I have to run the test installs for CFAsterisk 2.8 and CFFreeSwitch 2.8.
The installations for CFSecurity, CFInternet, and CFCrm 2.8 are implicit as they are referenced/included by the above projects, so there is no point spending time doing explicit installations of those schemas.
Stay tuned. Service Pack 3 should be reissued today.
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.)
DB/2 LUW only supports 31 digits for DECIMAL types (the most restrictive of the databases tested to date.)
All of the databases have been installed to Oracle XE, uncovering a number of model changes that had to be made to eliminate errors and warnings. A number of defects were found in the Oracle rule base as well, because Oracle actually compiles its stored procedures when they are defined, while those errors went undetected with PostgreSQL because PostgreSQL only compiles stored procedures when they are actually invoked.
The defects in the Oracle rules have been propagated to the other database rules, so all of the database scripts have been affected.
You may see warnings/errors in the Oracle database installation log about "invalid" objects. They should 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.
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.
I managed to get an Oracle XE database running on my Debian "Jessie" amd64 box! It is not easy, and I can't even begin to document all the bits and pieces I had to work through with help from the 'net to make it work, but it CAN BE DONE!!! Take heart!
This means that I can now test the database scripts for one of the biggest RDBMS vendors there is.
I also plan on installing my copy of DB/2 LUW on this box so it can be tested as well. That means the only databases I won't be able to test are Sybase ASE and Microsoft SQL Server. Maybe I'll give another go at getting Sybase ASE running, now that I've worked through the process for Oracle. Maybe I can make it work now. Time will tell.
SQL Server will just have to wait for Microsoft's planned release next year, and then only if there is a free developer's edition available.
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.)
Oracle only supports 38 digits for NUMBER types (the most restrictive of the databases tested to date.)
When index columns are compared, the IsAscending attribute is now considered and reverses the sign of the result if the column is descending. This has been done in preparation for supporting the PageData table attribute.
The database queries need to consider these attributes next by implementing ORDER BY clauses over the primary index columns, specifing ascending or descending as appropriate (this is an ANSI SQL feature, so the same rules can be used by all of the databases once it has been done for PostgreSQL, except for the syntactic sugar that DB/2 LUW requires for its database script line terminators.)
I need to consider the Ascending/Descending flag of the indexed columns.
For the comparison objects, this is a matter of toggling between returning values of 1/-1 during the comparisons based on the flag for the indexed column.
For the database reads, any read which is expected to return multiple records will have to be modified to sort by the primary key index columns so that the result set is predictable.
This is prep work for implementing PageData.
Note that any table which sets PageData="true" should have its indices sorting in descending order so that the newest data appears first in the GUI.
I think I sort by primary key in the GUI if there is no Lookup nor Alternate index specified for a table. I'll have to check on that and make sure it is so.
The database names for the relationships were lost in the models and had to be restored. I've also added a validation check to ensure that database names are unique for the tables, indexes, and relations as a whole, not just within their class hierarchies.
The models have all been rewritten by the CFBam 2.7 Editor and the 2.8 projects have been remanufactured, built, and repackaged. There are a number of defects that were corrected since Service Pack 1, and a lot of nice-to-haves have been coded as well.
The contents of the edited CFBam 2.8 model were backported and used to manufacture the CFBam 2.7 code used by this release. This was the final recursion test of the CFBam 2.7 Editor. It is now complete.
The final verification was to compare the output of the factory run with the pre-backported code with the results of a run with the backported model. There were no changes in the output, confirming that the recursion was correct.
The InitValue of id generators are now set, and the MinValue for the numeric id generators as well. You can, of course, override the default values with the editor, though normally you would not need nor want to do that.
Types cannot be nullable, so they are now forced to not null except for the Blobs, which must always be nullable. You can no longer specify whether a Type is optional or required -- it is always not null.
The name changes from columns to index columns and from index columns to the relation columns are now propagated automatically when saving a model or when validating it. In addition, the short name, description, short description, and label are propagated. As a result, you can no longer edit those attributes in the IndexColAttrPane nor RelationColAttrPane.
The name of an IndexCol is set by selecting the indexed column, as those values have to be coordinated. It should not be set manually. However, if you change the name of a column after creating an index over it, the names will not be coordinated, which is regrettable. Perhaps someday I'll write extra code to take care of that as part of the validation process or something.
The screenshots have been refreshed to show the changes made to the way qualified object names are evaluated. The documentation should be stable now.
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.
In order to insure the most relevant portion of the selcted object's name is displayed, position the caret to the right end the CFReference Editor text field whenever a value is chosen.
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.
There were a couple of "to be done" comments in the documentation regarding tables and relationships. I've filled out those sections.
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.
Removed the documentation model and scripts; only MSS Code Factory itself is being republished as a result.
The documentation is now complete, so the distribution has been repackaged with the latest updates. It isn't fancy documentation or overly detailed, but it should be enough for an experienced business analyst to use the CFBam Editor to manage their models.
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.
The UuidGen iterator for the SchemaDef needed to be kept. Restored from 2.8 code.
UUID generators can't really be dispensed by tables -- they're programmatic.
The handling of InitValue for the various String and Text types requires that the value be emitted as an empty string if the column or type is required, otherwise the copy-constructors will fail trying to copy a null to a not-null attribute in the manufactured code. In all other cases, an empty field value means the value is null, but not for these initializers.
The screenshot documentation set is also bundled with this release, though there is no text explaining what to do with those screens and forms yet.
The screenshots have all been collected and organized. Next I'll need to actually provide some write-ups about what to DO with the forms.
Screen snapshots for the schema forms and data type forms have been added. This was so much work I figured I had best check it in and post an update before I deal with the tables and their components.
Screen snapshots for the hierarchy forms have been added. I decided I'll spend today gathering screenshots, and work on the documentation for them later. I'll probably wait until I've got all the screenshots gathered before I post another update.
I went through the documentation so far and brought it in sync with the 2.7 release. I'll be working on the documentation for the next little while, and just posting updates of that, not of the core engine and its installer. No point updating product version numbers just for documentation.
You can always go to the project website copy of the documentation rather than downloading it, too.
With a couple more things checked regarding the DefSchema restrictions on what you are allowed to do with the data presented by the CFBam Editor, I am now ready to release MSS Code Factory 2.7 Service Pack 1 to the world.
I am very pleased to note that in only 12 days I enhanced the RAM database, corrected bugs in the relational databases, and created and tested the CFBam Editor. It has been a VERY productive two weeks.
Maybe I should get some sleep once in a while, eh?
There were some typos and errors in setting the enable/disable states of the MoveUp, MoveDown, View, Edit, and Delete buttons in the ListPanes. This has been corrected. Now if you are editing an object, you can't do ANYTHING with its sub-objects.
I have also gone through all of the table column types to create them, make sure their optional attributes get persisted and restored from the XML model file, and deleted them again to make sure that the deletes work as well.
I went through the optional attributes of the Table as well, and found some bugs which have been fixed (population of lookups for the reference editors.)
I also neglected to note that I tested the creation of the DelDeps some time ago, though I had already exercised that code pretty thoroughly so I wasn't surprised to find it works -- but I wanted to test the persistance of the definitions to the XML model file.
I have also tested the optional attributes of the relations and indexes to confirm that they get persisted and restored properly.
I think I am done with beta testing. I'm going to cogitate on that theory for a while and see if I can come up with anything else I want/need to test before I release service pack 1.
GenerateId is a tri-state checkbox: true, false, or null (question mark.) However, the initial value for nullable columns is null, which meant you always had to click that box when creating columns, which isn't a very nice UI. So in the ValueList I now default that attribute to a "new Boolean( false )" so that it defaults to the most common value instead of null.
The reference lists are now all sorted, and the ServerMethod reference lists are properly populated so you can add server methods now. I also cleaned up the formatting of the save output for the server methods and their parameters.
When you select the indexed column of an IndexCol in the attribute pane, the name of the indexed column now auto-populates the name of the IndexCol, as they have to be the same.
The same is true of selecting a FromIndexCol for a RelationCol -- the name of the FromIndexCol is used to populate the Name of the RelationCol.
You'll find samples in the updated com-testing-TestProject-1-1-TestSchema.xml model file in the MSS Code Factory 2.7 model-2.7 directory.
I still need to play around with the various optional attributes, and there are a couple of "clean up" items I want to take care of.
The essential functionality of the CFBam Editor now works. I've been able to create the model com-testing-TestProject-1-1-TestSchema.xml, which is in the MSS Code Factory 2.7 model-2.7 directory shipped with this release. It has a base table definition, a subclass table, and the columns, indexes, and relations that were required to define a chain for the subclass table.
Now I need to play around with the various optional attributes of the objects, and make sure that they get saved to the model file properly and are parsable when restarting the editor.
Once that is done, I'll shift my attention to some nice-to-haves like alphabetical sorting of lists that are currently sorted by primary key. Technically that isn't a functionality requirement, but it will make the editor easier to use.
There were some nasty issues cropping up with creating subclass tables caused by a failure to clear the Prev/Next links of the copied table column data. That one had me scratching my head for a fair bit, because everything looked ok in the debugger, but what I was seeing on the display made no sense -- the columns of the superclass table in a weird order.
The license lists in the SchemaDef attribute pane were still coming up empty, preventing you from creating a model from scratch. I fixed that, too.
There were some inconsistencies between mssbam-2.7.xsd and the elements produced by saving a file with the CFBam Editor. Those inconsistencies have been cleared up; they were harmless, but annoying.
Last but not least, the GenerateId attributes were not being produced when a table column indicated that an id should be generated for it, resulting in data loss when saving a model and reloading it.
When saving a file for a schema that included tables with no ClearDep or DelDep specifications, an exception was being thrown because there is no head of an empty chain of dependencies. Now if the iterator starts out empty, the methods just return without trying to save non-existent data.
With this release, the validation is complete. I can't think of any other rules for the definition of a model that can be automatically validated. If something comes up in the future, I'll add it, but for now the validator is done.
Note that the factory itself also invokes the validator, and refuses to manufacture a model until it passes validation checks.
There were some design flaws in the CFAcc(ounting), CFAsterisk, and CFBam models detected by the new model validator. These have been corrected, the 2.8 projects remanufactured, built, and repackaged with the corrections.
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 editor forms and attributes for those same values have been removed from the 2.7 models as well, and so stripped from the editor.
Note that if you made reference to those attributes in your models, you'll have to edit them to remove them before you can manufacture your code with this build.
All of the 2.8 projects have been remanufactured and clean-built to make sure that there were no problems with syntax errors or "cruft" in the models.
This was done because I decided the CFBam 2.7 Editor was kind of cluttered with all of those fields that were for editing attributes I don't use in the rule base.
You can now select a License for a SchemaDef in the CFBamEditor, and the initial draft of the new project documentation is delivered with this installer in the "documentation" directory. The documentation is also available on-line.
To run the CFBam Editor, use "CFBamEditor27.bash model-file-name-without-dot-xml-or-path-to-file [trace]".
If you run it without a model name, you'll be presented with a "clean slate" for defining a model from scratch. Once you've created your Schema, the first thing you'll want to do (at a minimum) is import the SchemaRef for the CFSecurity model.
If there is any content to your model, you'll want to save/export the model after adding any new SchemaRefs to it, so that you can reload the model and have the internal database sequence its data correctly with the referenced import. Otherwise you are going to get bizarre problems trying to work with the editor. If you're starting from scratch, you have no content, and as long as you don't add new content before adding all the SchemaRefs you want, you can go ahead and do your edits without an extra save-and-reload step.
By default, model files are saved to the first directory specified in your model path list of the .msscfrc file in your home directory. You need to have a properly installed copy of MSS Code Factory for the editor to find the model files, with valid model path entries.
If you've worked with the raw XML files, you'll have no trouble with the editor. Maybe I'll write some proper documentation for it one of these days anyhow, and ship that documentation with the project installer.
You do NOT need to download the net-sourceforge-MSSCodeFactory-CFBam-2-7-[version]-editor-installer.zip file -- the editor is included with the main MSS Code Factory installer now. That is why the installer grew from roughly 22MB to over 47MB. :)
I want the latest version of the factory to beep when errors are detected in the rule files, but not when parsing the model. It typically stops running if there are parse errors in the model, so you don't get in a situation where you don't realize there is a problem.
Similarly, the expansion of rules now generates beeps during processing if exceptions are caught, so you know you model is invalid or there is a problem with the rules.
When the toolset, ruleset, and rulecartridge parsers catch a parsing error, they now beep so that you know there is a problem with the file syntax or the rules it defines.
It just dawned on me that the CFBam Editor qualifies as a "real application" built with the MSS Code Factory technology. There is no longer any need to finish the CFAcc 2.8 project just to prove a point, though I might work on it out of sheer boredom.
I've already proven you can write a real application with this tool in record time.
The editor is now feature complete and ready for beta testing. The earlier "beta" really should have been called an "alpha", considering how much more work I put into it to get to this state. I haven't exercised all possible branches of the code; only practical use will do that.
I only have one official beta tester other than myself, but once we're both happy with the editor, I'll be releasing it with MSS Code Factory 2.7 Service Pack 1. (There are a lot of enhancements to the rules and models that have been made, so a service pack is overdue, but I don't want to release one without the editor in a production state.)
I've decided against coding the model validation. You'll find out soon enough that you have an invalid model when you try to build your source, or when the factory starts beeping at you because of rule expansion errors while trying to manufacture your model. I don't think I could come up with a validator that could guarantee a model is valid without putting in months of work, so I'm just going to scrap that concept as it doesn't really buy all that much in the end.
At least not for me -- don't forget I had to HAND edit all my models for YEARS, so if you have to go through some minor pain trying to manufacture and build bad models, you're still getting off easy. Especially considering the price of this tool. (Free.) :)
So that means I am now done with features for the CFBam Editor. I just need to do some more testing and wait for my buddy to do an official beta test before I release the official production version of the editor as the first Service Pack for 2.7.
It also means it took 9 days to get to a "feature complete" state on the CFBam Editor from the start of this wee project. Not too bad at all for a model of nearly 150 tables (even though you can't edit a huge number of those tables in the editor. There are still about 100 objects that you CAN edit.)
I took the time to go through all of the ViewEditForms and ListPanes to tweak the settings of the enable and disable states of their buttons so they would respect the restrictions of the DefSchema references made by themselves and by their containers or siblings. I'm reasonably confident that you are no longer allowed to do anything with imported/referenced data that you shouldn't be able to.
You could, of course, establish Table Relations that break the object model of the imported model by imposing an artifical parentage or other relationship that forces a 1:0,1 link where multiple instances had been previously allowed, but I can't think of any easy way to prevent that. You'll just have to be aware of such things when working with models; it isn't like the audience of business data analysts aren't already aware of such issues when dealing with foreign application data. This is just a different way of binding foreign application data WITHIN the object model rather than as an externally referenced entity.
You may not define a subclass of an imported/referenced table, only the tables local to your model.
Chains already prevented you from adding new instances if their containing Table has a non-null DefSchemaRef, but that code had to be added to the Index list pane. The only thing you can add to an existing Table is new Relationships.
You can't edit or delete a table that was imported/referenced, only view it
Being in view mode over the table will let you add additional relationships.
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.
Errors now make the computer go "beep".
It now does everything needed.
The customized list panes that were missing have been added, and the labels have been gone through with a fine-toothed comb to ensure that they are all correct. Unless I come up with some custom features that need to be added, this is it for the editor, I think
The one BIG custom feature is that schema validation routine I'd mentioned earlier.
The CFBam 2.8 model now has labels on most of the columns that don't participate in relationships, and on the relationships themselves. Just so the default manufactured JavaFX forms look a little better and don't need as much cleanup as I did for the 2.7 CFBam Editor.
Similar changes were made to the 2.7 model in the 2.6 version of the factory and applied to the code base for 2.7, though you shouldn't see much of a difference in the CFBam Editor due to the amount of customization that was done.
The remaining customized forms have had their field ordering tidied up and made consistent, and most of the labels have been updated with something a little more presentable.
That is pretty much it for the clean-up efforts; what remains is debugging, testing, and bug fixes as the editor is gradually made ready for production.
Oh, and that model validation code segment I'd mentioned to be placed in the main part of CFBam so it can be used by the engine to pre-validate models before they are manufactured.
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.
The TableCol looks much like an atomic type so I've made its field arrangement consistent with with those panes.
The attribute panes for the atomic types now present their fields in a more logical sequence based on what you would want to enter for data, rather than the default ordering imposed by their position in the data hierarchy (which presents them top-down from base class to most detailed.)
I've similarly updated the Value list pane to use a similar, though not identical sequence of fields/columns. There is certain information you should be able to get "at a glance" from the list without needing to scroll around.
It should have been a trivial thing to implement, but it was not. Many thanks to stackoverflow.com, though it would have been nice if they could have collected all of the tips into ONE article instead of having to fix one line of code, get a new exception, Google for the new exception, and fix one more line of code over and over and over again.
THREE FREAKIN' HOURS I WORKED ON MAKING IT GO "BEEP!!!"
I could NOT accept the computer defeating me on something so bloody simple as making it go "beep". So I dug and I dug and I chased one error after the next until the damned thing worked.
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.
Toolkit.getDefaultToolkit().beep() is invoked when an exception is logged through CFConsole. This doesn't seem to work under Debian for some reason, though it is the oldest and simplest approach to making noise that I used.
Rather than trying to catch all possible errors in the CFBam Editor ahead of time, what I'll do is just deal with errors that cause exceptions and tracebacks.
Then I'll write a model validator that can be invoked manually from the editor to check the model for conflicts and errors. That way the validator can be used by the main factory itself as well, as I'll be writing that validator code in the custom engine package of CFBam, not in the custom editor package.
Just because a model is valid while you are editing it doesn't mean it won't have conflicts arise when it is imported/referenced by another model, so the user isn't necessarily going to be creating or updating the objects that are in conflict.
There were non-recoverable exceptions occuring if you tried to save a duplicate column name to a Table. Now that will no longer result in an error condition, and you can correct the Name and re-attempt the Save.
The CFBam Editor now allows a second argument to its command line: trace or notrace. The default is notrace, indicating that exceptions should not be logged to the system console. The default behaviour of CFLib is to trace unless it is told not to.
Whether a stack trace is printed or not is now configurable as a static value of CFConsole.
Disable the user-defined sorting for schema data types.
When creating or updating a Table, the Name and ClassCode are now probed to determine if the values specified are already in use by a different table. This should eliminate most of the exceptions that can be thrown while working with a Table object.
It took an incredible amount of code to do it, but you can now specify the Superclass of a Table when it is created by simply picking an existing table from a Combobox before you Save or Close the Add window. If you wish to change the Superclass relation later, you have to do it through editor surgery of the created Superclass Relation, which isn't the easiest, but I couldn't think of any way of easily automating the process without causing a lot of other grief if column names were to change as a result, or if there were relationships to the primary index of the table whose inheritance you were trying to change.
Once again I am out of ideas for "quick hits" of improved functionality, though I did find that the default field ordering on the Table attribute pane was pretty bad, so maybe I should go through all of the customized attribute panes and tidy them up. Not right now, though -- I've done enough coding for the moment.
There were some show-stopper exceptions being thrown when adding new Relations that have been corrected in the CFBam Editor, and the field validations have been fleshed out more thoroughly, though there are probably still some missing validations.
The CFBam Editor is now packaged with the MSS Code Factory distribution.
MSS Code Factory 2.7 as a whole comprises of 3,895,752 lines of code, of which 598,123 have been customized, for a total of 15.3% custom code (much of which was copy-paste-edit customization, I admit.) So even on the factory itself, roughly 85% of its code was manufactured by an earlier release of the tool.
That is why I call it a "genetic expert system" -- each generation "breeds" the next by writing the bulk of it. There have been 7 generations of the tool to get to this point (1.1, 1.3, 1.5, 2.1, 2.3, 2.5, and 2.7.) Even numbered releases are for internal use and are not considered full generations.
|MSS Code Factory 2.7 Sizes|
|15.3% of the code has been customized in total|
With the addition of the DelDep and ClearDep editor customization, the CFBam Editor is now ready for beta testing. I'm sure I have still forgotten something, as I usually do, but for now I've done everything I had initially planned on doing for editor customization.
The oldest note about the editor is from 2016.03.09, which means I created the customizations for the editor in only a week. How many people do you know that can create a custom editor for an object model of roughly 150 tables in a week?
The Relation attribute pane has been customized to use a set of four inter-dependent combo boxes to let you edit the PopDep path for the relationship. There is a chance there are still bugs in that new code, but I did my best to test it as thoroughly as I could, as such inter-dependent code tends to be more prone to bugs than "typical" user interface code is. Particularly in this case, as the choices in those combo boxes form a hierarchy of objects that have to be created, updated, or deleted according to the changes the user has made rather than just affecting fields that always exist such as when programming country-province-city address interdependencies.
The save/export of models now defaults to the first model path directory specified by the configuration file. You can change directories, of course, but it makes more sense to default to saving them on the MSS Code Factory model path rather than in some arbitrary directory.
I'll work on either the customization of the ClearTopDep or DelTopDep attribute pane next, using the code from the Relation attribute pane as a starting point. There are some differences other than the names of the objects, though, because you are editing the top dep itself rather than the table that contains the sub-objects as in the case of the PopDeps for a relation.
Next up is some serious customization of the RelationAttrPane to let you set the attributes of the PopDep reference and save the sub-objects after posting the Relation itself. The default editor code produced by the factory is very crude for such nested object editing, particularly when all you really want is a set of four choice boxes that let you pick relationships of the table (including inherited ones), enabling and populating the choices of each of the four choice boxes in sequence as they are selected, so you can easily navigate through the relationships available.
Similar changes will be made to the was a DelTopDep and a ClearTopDep are edited; they won't be handled using the default crude editors for much longer.
Off the top of my head, that was it for the major customization work I had planned. I'll have to play with the editor after I've done that work and see if there is anything else that is too clumsy to be used easily. Editing models is never trivial, but it shouldn't be clumsy to do so.
The SchemaRef forms have been fully customized to present you with a list of the model files found on the path, let you choose one, and import it. If the model has been previously referenced, you are informed of the fact and not allowed to proceed with saving the new instance.
If the model has other SchemaRefs, they are automatically created if need be so that they are part of your model as well.
All of the data from the referenced schema is automatically made part of your model.
You can not delete a SchemaRef through the editor. You'll have to perform surgery on the save file if you want to do that, because the referenced schemas become an integral part of the data model and trying to untangle it from the model would be an absolute nightmare.
When I saw that the next release was a 512 release, I had to do one more release today. :)
IsChainRelation returns "yes" if the Relation is a Prev or Next link of a Chain defined by its Table. This is now used to decide whether to include a Relation in the attributes of an AttrPane, though the binding has existed for some time and such filtering was already being done for lists.
I think I'm going to try to take a break from the computer for a few days. Things are at a good break point right now. Everything that has been done works, such as it is, and the next couple of pieces are relatively large and complex for the CFBam Editor (at least I expect them to be; I could be wrong about that. They could turn out to be trivial to implement, just time consuming.)
So I think I'm going to shoot for about a week off, and pick things up next week. Listen to some tunes, watch some archived video, maybe even do a bit of reading.
A subset of the DelDeps I used to have in the CFAcc 2.8 model have been restored. You will not be able to delete any finalized data without the other DelDeps that were causing problems, but normally you don't want people deleting historical data from an accounting database anyhow so that shouldn't be a problem.
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 CFBam 2.8 database creation scripts.
Oh happy day! This was a brain fart I am GLAD I woke up with! :D
CFLib 2.7.13503 reduces the Number MAX_DIGITS to 65 from 100 in compliance with MySql restrictions. The models have been updated accordingly.
There were some errors in the database scripts that had cropped up from changes to where I specify the containers in the various models. These defects have been corrected. I have now tested all database creation scripts for MySql and PostgreSQL for all of the 2.8 databases.
I also spent a couple of hours trying to fix the problem with the CFBam 2.8 database creation scripts, but everything I tried caused cascading problems worse than having to edit a couple of variable names by hand. So you're just going to have to live with that if the problem crops up for your model; there is no easy fix. If I had all the database engines to test with and were willing to spend about a week working on a fix, I MIGHT be able to come up with a solution, but I couldn't guarantee it. So it isn't going to happen.
MySql only supports 65 digits for numbers.
All of the database scripts, XMsg support, database loaders, etc. have been stripped from the source tree and builds. Only the essentials required by MSS Code Factory 2.7 and the CFBam Editor are now built and delivered.
You really shouldn't edit the prev/next links directly; those get managed by the MoveUp/MoveDown buttons. So rather than let the user corrupt the database, I've removed the widgets so they have no way of changing the links manually.
A Prev/Next Chain has been added to the SchemaRef object because the sorting of those objects is important to the behaviour of the factory itself. The references have to be listed from the bottom up, so you can't just arbitrarily process them in the order that they were created in the GUI -- you have to let the user control the order.
The bulk of the CFBam Editor customized. What I have to do yet is some rather hairy full customization work for editing the PopDep, DelDep, ClearDep, Relation, and SchemaRef objects. The default behaviours for those are insufficient and too clumsy for words. But the rest of the editor is in pretty good shape -- you might want to download a copy just to play with a bit. I figure it will take another 1-2 weeks to be in alpha/beta test-worthy state, though.
You aren't allowed to change the DefSchema lookup, so the editor for that attribute has been disabled. Whenever you see a value in that editor, you know the object was imported by a schema reference, restricting what you are allowed to do with it.
Oops. Infinite loop.
The List and EltTab panes have been customized to adjust their button displays, tabs, and behaviour according to what is needed to support the OptionalDefSchema() references of the objects.
I've also removed the element tabs that were used to access the PopDep list from the RelationEltTabPane, as I intend to do some serious customization of how that object is edited.
The lists of DelDeps and ClearDeps still appear in the TableEltTabPane, but those panes will be replaced by seriously customized editors at some point. The default interface as manufactured is far too crude for practical use.
The initial restrictions on the GUI have been imposed. Now only the schemas within the loaded version are displayed, or, if no version was loaded because no model name was specified on the command line, all schemas are displayed that you create during your session.
This hides the schemas that were loaded by reference, unless they appear at the same point in the model hierarchy (your hierarchy naming is important to prevent this.)
In addition, all of the ViewEdit forms hide the Edit, Save, and Close buttons if there is a DefSchema associated with the object, indicating that it was imported from a referenced schema. You cannot change most such objects, so eventually I will restrict the List functionality as well as the ViewEdit forms themselves. One of the few exceptions is that you can add relationships to an imported table, provided that they are Children, Details, or Components. You can not add indexes, columns, or chains to an imported table. You can also add DelDeps and ClearDeps to an imported table.
All other imported objects are entirely read-only. You can't change the order of index columns, relationship columns, or otherwise cause the imported model to change.
Only that select set of operations on an imported table are allowed because those types of edits do not affect the ability of applications written to the imported schema from functioning with your application's server and database.
In case I never made it clear, one of the goals of MSS Code Factory is to take functional composition to the application level. If you import CFAcc 2.8 into your model, you should be able to run the CFAcc 2.8 client against your database without changes. Similarly, you can run the CFSecurity 2.8 client against ANY application created for the 2.8 release level, as all applications include that schema reference at a minimum.
Should you choose to work with the in-memory storage system, remember that it is not a full relational database. It is closer in its internal design to an older style of database known as a network database. It can also be horrendously inefficient, because it maintains hash tables over every possible permutation of index for every insert or update using a brute-force approach.
However, it can read data at blinding speed.
If you are going to delete data, be aware that it requires you to specify a very detailed set of deletion dependencies. You should not rely on automatic cascading deletes as you would with a relational database, because although such behaviour is coded, it is very unreliable and prone to integrity constraint violations.
If you don't specify a sufficiently robust set of deletion dependencies, the database can easily corrupt itself, as it performs the chain unlinking and the ClearDep and DelDep processing before it checks for integrity constraint violations.
Ideally you want your model to implement DelDeps such that the deletion of any object in your model will result in cascades to delete all related objects, rather than allowing integrity violations to be reported. As I've already said, an integrity violation on a delete likely means that your data has been corrupted.
Still, within the bounds of what it was designed to do (fast reads), I am very pleased with it. This code was the first thing I worked on with MSS Code Factory after doing the initial object model, as I needed the storage system in order to be able to write the rest of MSS Code Factory itself.
In fact, the first five or six 1.x releases were focused almost exclusively on working out the kinks in the object hierarchy and the in-memory storage of those objects. It was difficult enough that I even gave up on the project a half dozen times during that early development. Fortunately I kept going back to it after a few weeks or months, once my frustration had died down.
There are no security, locking, ACID, or other "nice" features of a real database. But if you're doing something like trying to maintain a call record list that is maintained by one single-threaded service, it just might be the ticket you're looking for.
This has been one hell of a long night because this is the first time I ever tried to delete a complex object from the RAM database, so there was a LOT of debugging to be done. But eventually I did wrestle the beast known as the "CFBam Editor" into submission.
The 2.8 projects will be remanufactured and shipped as well.
Functionally equivalent code to the ClearSubObjectLookups sections of the stored procedures for the various databases has been added to the RAM delete implementations.
The DelDeps and ClearDeps are processed in reverse order by the factory. So you specify them in top-down order from most general object to the lowest sub-objects, not from the bottom up.
The ClearDeps now build clean for the RAM deletes. There are two more pieces of delete code to be converted from SQL to Java for the in-memory database. All of the CFBam 2.7 Java code has been remanufactured by 2.6.13486 and rebuilt.
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.
I ported the CFBam 2.7 model changes forward to the 2.8 model included with MSS Code Factory 2.7, and ported the rules forward from 2.6 that needed to be modified in order to produce code for those model changes.
I be manufactured CFBam 2.8 and tested the database creation scripts for PostgreSQL -- they don't work properly. The changes I made to the code result in missing variables for the 4 new scripts that are supposed to implement moveup/movedown for DelDeps and ClearDeps. However, I'm going to check in the code as-is and deal with the problem after I've had some sleep.
The chain handling rules from 2.6 have been brought forward to rewire the Prev and Next elements of the Cur element to each other before proceeding with the deletion has been implemented. This does not necessarily mean that all deletes will work, as I have yet to implement the cascading deletes, the ClearDeps, and the DelDeps. But once I have finished with all of that, the RAM database should be functionally equivalent to a real database, save for the fact that it can get corrupted if there are transaction errors because it has no ACID integrity support.
I have also implemented the user-defined ordering for the save/export of EnumTags from the CFBam Editor.
The problems I was having turned out to be bugs in the RAM implementation of moveBuffUp() and moveBuffDown(). The code was already forgetting the relationships when a buffer is applied to the object, which happens during the propagation of the result sets or a read in the "realize" code for objects.
The engine rules have been updated the same way the 2.6 rules were to remove this invalid/unnecessary code. I will be manufacturing the 2.8 code base and shipping an update tonight to remove the implementation.
The file save/export facility now respects the user-specified column ordering.
The code has been remanufactured to correct the bugs when moving class hierarchy data.
The rule changes have been forward-migrated and are included with this release of MSS Code Factory itself, and are ready to be applied to the 2.8 code base in the future (I want to implement the DelDeps and ClearDeps for the RAM database before I bother with refreshing the 2.8 code, as it takes 7-8 hours to upload a release.)
You can now sort the rows of the tables that support user-defined ordering to your heart's content in the CFBam Editor. However, as the file save/export facility does not implement user defined sorting on it's data sets, these changes will have no useful impact at this time. I'll work on the editor save functionality later today. A fix for the issue should be posted before tomorrow morning.
The in-memory RAM database implementations of moveBuffUp() and moveBuffDown() have been implemented and debugged. You can now sort data in the CFBam 2.7 Editor.
However, the file save facility does not currently respect user ordering of data, so this is only the first step. I have to work on the user-defined sorting in the file formatter before this new feature is actually useful.
The Java layers have been remanufactured and rebuilt to ensure that the stale relationship bug doesn't crop up in any further work on the CFBam Editor. 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 while you were sleeping at the desk. :P
In other words, while I haven't seen it crop up, this was a MAJOR multi-user bug.
It is necessary to forget relationship linkages when realizing an object, even if the current instance from the persistent store is being kept. Otherwise things like the prev/next links can cause you to go into infinite loops in the CFBam Editor, causing Java to run out of heap.
CFLib 2.7.13466 corrected the formatting the XML numeric output to force digit strings instead of the default exponent formats Java uses for larger numbers.
The files saved by the CFBam Editor are now readable by the CFBam custom parser/loader, with both CFBam 2.7 and CFDbTest 2.7 having been used as test data to ensure that all types and elements are exercised. An additional dependency for the data types has been implemented when deciding whether to emit a table during a given pass of the emission loop -- it is possible for a TableCol to reference an id generator that specifies a table that hasn't been emitted yet as it's Dispenser, which means you could get in a situation where the DataType of the TableCol hasn't been emitted yet.
Force non-exponential output of all numbers for XML.
The new formatXmlStringWhitespacePreserve() method is used when exporting/saving models from the CFBam Editor. The Switch scripts are handy for updating library verions; I don't know why I didn't migrate them earlier.
The whitespace preserving version of formatXmlString() does not convert newlines and carriage returns to ampersand-escapes.
I am ready to test the saved files to see if they load/parse properly. I think I have all of the various elements and attributes of the BAM 2.7 format coded now.
As the code for something other than the editor itself has been changed in CFBam 2.7, it is time to refresh the command line tool as well. Plus I made changes to the rules and models, so I wanted to push those changes out anyhow.
The text editors now fit on the initial/default window size when scrolling through the attributes of a Table or SchemaDef with the optional code customization fields/attributes/elements.
The rules for 2.6 have been updated to actually calculate the height of the AttrPane text widgets based on their ShowLines values. The rule changes have been brought forward to 2.7 so they will get applied to the 2.8 code base eventually.
The customization edits for the optional elements of a SchemaDef or a Table have been increased from 5 lines to 20. Even that is pretty restrictive when you are editing code blocks in the editor, but I don't want to make the GUI forms obscenely huge, just workable.
The various server methods are now emitted as TableAddendums.
I can't think of any other objects that need to be fleshed out except the atomic types, so it will be quite a while before the next update. There is a lot of code to be written to deal with the entire type hierarchy.
The optional text elements of the SchemaDef and Table are now emitted.
I've also realized I completely forgot about the remote procedure prototypes. I think I'm going to do those as table addendums and emit them after the DelDeps -- I don't want to end up with so many dependencies on data that I can't exit my loops. It is easier to just make sure all possible definitions will have been specified before the stored procedures are added. I'd have to do them as TableAddendums in some cases anyhow, so I may as well do them all as TableAddendums.
Once those are done, all that remains are the atomic type emitters that I've been avoiding for two or three days...
All of the Table attributes are now filled out, and the way tables are ordered has been adjusted to allow for the Superclass relationships as well as the QualTable attributes. This means the tables are no longer emitted in nested form, but I'd rather have loadable data than pretty data.
The export/save of the ClearDeps and DelDeps has been coded.
That leaves the remaining attributes of a Table, the atomic attributes, and the various text attributes of the SchemaDef and Table that are emitted as individual elements (there sure are a lot of those used to customize the code produced by the factory. They will take a while to code.)
The saving of Relations with their RelationCols is now complete.
I think I'll work on the ClearDeps and DelDeps next.
The version tags got confused tonight. I'm fixing them.
The Table attributes have been partially fleshed out, but are still incomplete. TableCols have been fleshed out, and the Value and Atom attributes of the atomic types and columns have been fleshed out, but there are still all the type-specific attributes to be emitted. Relation attributes are partially fleshed out, and the RelationCols have been completed. SuperClassRelation specs get emitted as well, and enough of the Relation attributes are emitted that those are as complete as I've ever used them for actual models.
I haven't done anything with the DelDep or ClearDep attributes yet, just their names.
I think I'm going to get some sleep. There is no way I can finish this in one go.
I finished coding the emitters for the SchemaRefs and for the [Primary]Index definitions, along with the IndexCols. The "elephant in the room" that I'm avoiding are the types and columns. They're going to be an inordinate amount of work; I'll get everything else done first.
The oddball dependencies I'd mentioned earlier have been coded for when I emit the relationships for the tables. That was a fun bit of code. Not really difficult per se, but more interesting than your average XML formatting routines. :)
The latest version of CFBam 2.7 has been used to refresh the factory. There are no changes to the functionality of the factory itself; the changes were made to satisfy editor requirements. However, I like to make sure that everything is on the latest version of code at all times.
The model loader now properly establishes OptionalLookupDefSchema linkages for the PopDeps, DelDeps, and ClearDeps. These are used by the BAM Editor to determine whether an object was defined by the current schema or inherited from a referenced schema. Only locally defined specifications get emitted.
I've outlined what has to be written to the save files, and discovered along the way that I need to add references to the defining schema for the DelTopDep and ClearTopDep objects so I can tell whether they were added by the schema being exported/saved.
I'm also going to have to figure out how to properly order the table relations -- any PopDep specifications have to be resolvable at the time a relation is defined, which means a given relation can't be exported until those requirements have been met. What I'm thinking to do is to add a hash table that itemizes the relationships exported so far. If a relationship is already in that hash table, don't re-export it. If any of it's PopDeps aren't in the hash table, don't export it. Iterate through the tables and their relations until a final run occurs where no relationships are exported at all. That beats the heck out of trying to come up with some bizarre sorting algorithm.
The ClearDeps and DelDeps are defined after the relations, so they don't have that problem.
I've already taken care of emitting the table definitions themselves in a tree hierarchy layout based on their Superclass relations. As all they can do is define columns and indexes during that pass, there are no other dependencies to worry about for the ordering of the initial table specifications.
Note that I've decided to only post a refresh to the CFBam 2.7 installer itself if I have to change the model for CFBam 2.7. Otherwise I'll just post editor updates.
The saved BAM now has some (incomplete/incorrect) content saved to it. I don't think I'm going to bother posting updates while I work on this, but you can keep track of the progress through github if you're interested -- I will be checking in the code frequently as I work my way through this mammoth effort.
There is now a "Save As" button that gets enabled when a SchemaDef is selected in the hierarchy browser, which will eventually allow you to export the model of that schema as a text file. For now the file is empty, but it does let you create one.
The command line interface now maintains its own version number which is distinct from the version number of the engine itself. That way I can still ensure that the messages let you know which version of rules and models you are running with, without having to rebuild all of CFBam 2.7 every time I do a release.
If you do not specify a model name as the first argument to the BAM editor, an empty model is presented so you can create one entirely from scratch.
You will never be able to load models by file name, because the whole model parser is built on the idea of scanning the list of model directories specified in the .msscfrc file for the factory configuration.
However, you can specify a model name as the first argument to the editor, and it will load that model for you. If you don't specify a model name, then "net-sourceforge-msscodefactory-2.8-cfbam" is used by default.
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.)
I replaced the TabPane with a custom form management pane local to the editor itself. No point giving "selections" when there is only one pane to select, eh?
The code has been successfully migrated for the custom SAX BAM parser code and MssCF customizations to CFBam 2.7 from MSS Code Factory 2.7 itself. The factory is now just a main with the rules and models and no real code.
The custom BAM SAX parser code and the MssCF customizations for the factory have been migrated to the CFBam 2.7 project from the 2.7 CLI. Now that this has been done, I will modify the CLI so that it copies and uses these jars, remove the old source code, and the CLI will atrophy to a main with the rules and models and virtually no code. I'll have to do a test run after I make those changes, of course.
The next thing I'll do with the model editor is shift the BAM parser from the CLI code to the CFBam packaging, which will likely require shifting the MssCF support as well, as the parser references the engine of the factory (I forget why; maybe I can remove that reference safely -- some of this code is pretty old and no longer necessary.) There is a good chance the "factory" CLI project will be reduced to little more than a main and the rules and models themselves.
I took some time to assess the state of the RAM database implementation. There are three key areas that I know need to be addressed for sure, as well as any other bugs or oversights that crop up in testing.
The moveup/movedown methods are not currently implemented. Chain links get established during insertion by the XML parser, but I'm not sure they are being properly established during general database inserts such as are performed by the GUI. Regardless, I know that chains and their prev/next links need a lot of work.
DelDep support is lacking, which means you can't really delete complex objects fromm the RAM storage. I'll have to use a radically different approach than the joins I perform in SQL, as there is no SQL engine to process where clauses and to figure out how to join the tables to identify the records that need to be deleted by a DelDep. This is going to be a fun bit of code, and likely will require a recursive implementation. We shall see -- I have some nested loop ideas as well, with one level of loop for each level of the joins that SQL do.
ClearDep support is also lacking. Although this won't cause errors when you delete objects, it will leave stale object references dangling all over the place. That is no good.
I might also need to implement automatic cascading deletes; I can base that on the DelDep support, though. Or I could just get lazy and mandate that all cascading deletes have to be explicitly modelled as DelDeps if you are going to use a RAM database (which is probably rather likely, as I am a rather lazy fellow at heart. :P )
It is going to be quite some time before even the basics of the editor are working, never mind the customization to prevent you from modifying imported objects in your model.
The initial production release upgrades the code produced by the factory to complete the integration of Enum type support. Even the factory itself now uses the Enum types, and the auditaction tables have been eliminated, along with all other Enum lookup tables that were in the models.
All of the 2.8 PostgreSQL database instances have been created successfully.
There were stale references to the now-obsolete auditaction table in the database creaton scripts. The rules have been updated to remove those references.
There were typos in some of the models migrated from 2.6. This also has been corrected.
The CFBam model had some duplicate database column names on the SchemaDef and Table objects, which resulted in database creation errors. Fixed.
There was a duplicate index name in the CFFreeSwitch model. Fixed.
This it the Beta release of MSS Code Factory 2.7. It is ready for testing and possible initial adoption. Once I have manufactured and successfully built all of the projects, and tested the CFAccounting application, 2.7 will go production and the older releases will be eliminated from the download server at SourceForge.net.
The initial alpha build of MSS Code Factory 2.7 runs and produces code. As it is based almost entirely on the 2.6 code base, this build should produce buildable code. However, it is completely untested at this point, so use at your own risk. It also lacks the full set of models, as I have yet to port those and their manufacturing scripts from the 2.5 release.
Once I have clean builds of all of the migrated projects, 2.7 will go production.
The PageData attribute was missing because I took my copy of the model before I'd made that change to the 2.6 models.
The code for the CFSecurity, CFInternet, and CFBam 2.7 projects clean compiles.
CFLib 2.7.13419 corrects an error in the implementation of CFLibBigDecimalUtil that was incorrectly comparing argDigits to MAX_PRECISION instead of comparing argPrecis.
The code now uses the AuditTypeEnum throughout and no longer references the obsolete AuditType table that used to be in the CFSecurity model.
The remanufactured and migrated code for CFCore 2.7 now builds clean. Whether it works is another story entirely.
This is the initial migration of the CFLib 2.5 code.