The Table.SuperClassDef is an old 1.6 attribute; all the rules rely on superclass relations instead, so I'm purging the old code tonight out of sheer boredom.
There needs to be a way of specifying that a relationship has to be cleared, similar to the way sub-objects can be specified for deletion by a DelDep. The only real-world case where this is needed so far is the CFBam 2.0 Relation.Narrowed specification, but one case is enough to force me to support such a feature. If I need it, I need it. And odds are someone else will need it someday.
As an example for a CFBam 2.0 Tenant, you would specify:
<ClearDep Name="ClearTableRelationNarrows" ClearDepChain="TenantSchema.SchemaDefTable.TableRelation.NarrowedRelation" />
The 1.11 model needs to enhance the Relation specification with a RelationDependency which is an optional chain of relationships extending the PickerPopRelation behaviour by allowing the specification of a relation chain. For example, the CFBam 2.0 specification of a Relation has to include a ToTable and a ToIndex. The ToTable can be specified by a PickerPopRelation -- it's simply a selection of the Table instances owned by a SchemaDef, so it identifies the relationship of the SchemaDef which identifies the tables owned by the SchemaDef. But the ToIndex specification has to depend on the ToTable specification, so it needs to identify the ToTable of the Relation first, and then the relation of the TableDef that identifies an Index of the Table. i.e. A chain or join of relationships, which have to be resolved dynamically at runtime and reject their own resolution if any of the relations in the chain have not been established.
This construct provides a superset of the PickerPop capabilities, so those constructs are being removed from the 1.11 BAM.
A second enhancement that is required is similar. I need to specify a DeleteDependency of a Table which follows a chain of relationships similar to the RelationDependancy, but this time with the goal of identifying sub-objects of a Table n levels down which have to be deleted before the an instance of the Table object itself can be. Instead of enhancing the GUI, this will require an enhancement of the stored procedures used to delete Table instances. I don't expect there to be any changes to the object interfaces as a result of this enhancement -- I think it can be handled entirely through the stored procedures. That will enable the deletion of generic complex objects, which currently can fail on cases like the Relation of a Table identifying an Index, preventing the deletion of the Index before the Relations are broken by the delete process in the current CFDbTest 2.0 "Replace Complex Objects" test. Once this issue is addressed, the "Replace Complex Objects" test will pass again.
Relation.PickerPopDep is described in the 1.11 log file. It's necessary for specifying dependent relationships, such as having to choose a Country before a State can be chosen.
In order to implement the Picker population properly, I'm going to have to add a new attribute to the Relation specifications of a BAM. I'll add an optional PickerPopRelation attribute to them, which references a Relation (one of Components, Children, or Details.)
When you specify a PickerPopRelation, the code will search through the object runtime hierarchy for an instance of PickerPopRelation.FromTable. When it finds such an instance, it will cast it accordingly, and invoke the member attribute accessor for the relationship.
If no PickerPopRelation is specified and the target of the relationship has no container defined, then the global set of target objects will be used for the population. Otherwise, if the container of the target objects is a Tenant or Cluster, the appropriate security object will be used to filter the population set.
Note that for now I'm not planning to support Add methods in the picker windows. There are a lot of complications to doing so, and I wouldn't *always* want you to be able to add an object without going to its container. I may someday implement yet another flag, say PickerAllowsAdd to enable such functionality on a per-relationship basis, if I ever work out the kinks to doing so.
Just to confirm that none of the 1.10 source was lost, the CFLib 1.9 was refreshed to CFLib 1.9.12224 and MSS Code Factory 1.10 itself was retagged as 1.10.12224 and rebuilt. It will be used to remanufacture the 1.11 source, which will then be repackaged with refreshed versions of CFLib and CFCore 1.11.
The 1.11 MSSBam model has had DefaultVisibility attributes with an intial value of "true" added to the Value, Table, Index, Relation, IndexCol, RelationCol, and Chain specifications. This will be used to determine the initial visiblity and enable states for the attribute widget panel and the list box columns for the specified objects in the 2.0 code base. I could just proceed with a default initial value of true, but I want to give the initial code produced for GUIs a little more control than that.
So all the necessary widgets are defined in the 2.0, but some will be made invisible and homed in on (0,0) in the display where they're out of the way. I have some ideas on adding configuration controls for the visibility of widgets as preferred by the user instead. I like configurability, even if it means letting you view things that you really should ignore, like PKey attributes.
The MSSBam 1.11 model has been enhanced with a QualifyingTable reference from the Table and supporting columns and indexes.
The rules no longer specify the GeneratorVersion in the manufactured comments; I'm tired of all the code changing for 1.11 when it doesn't need to.
The new JavaXMsg attributes have been added to the model as specified in the 1.11 programmer's notes logged earlier today. Note that there is an edit to a TableCol or IndexCol where an attempt is made to resolve an instance by Name, searching the AnyObj collections by name. This is erroneous -- you have to be guaranteed an appropriate IndexCol or TableCol instance, so it's necessary to probe only those filtrations of AnyObj by name. I forget whether it's an IndexCol or TableCol probe that's in question. It's unlikely I'll need to remanufacture 1.11 again with any further enhancements this close to production. :P
MSS Code Factory 1.10 had to be rebuilt using the existing jars for CFLib and CFCore 1.9 because the source code has been lost for CFCore 1.9. Fortunately this is not an active development branch and it's been many years since CFCore 1.9 was actually modified. The only harm is that the revision numbers for CFCore and CFLib are out of whack with subversion.
The latest models and rules being used to manufacture MSS Code Factory 1.11 have been repackaged and refreshed.
Update and refresh the license headers for the 1.10 code base and issue a new release built using that code. This includes the changes to the MSS Code Factory 1.11 MSSBam model.
The Chain specifications were using optional prev/next relation ids, but mandatory relationships. This inconsistency was uncovered while working with the Chain objects for 1.11.
The corresponding LookupIndex relationship from the Table to its component Index has also been specified. The idea is to specify the name of the LookupIndex in the opening table element, with the index itself instantiated as one of the sub-elements of the table.
At runtime, if the LookupIndexId is not null, it's used to resolve the Index and bind it to the Table. If LookupIndexId is null and LookupIndexName is specified, a name resolution is used to locate the index, and the LookupIndexId is ignored. i.e. Either can be specified, but the Id form is given preference for performance reasons (it's always faster to key a record by primary key than by alternate index.)
The singleton relation setters were checking to see if the value had changed before applying a change. However, this doesn't work after a read of a non-null value unless the relationship is resolved after the read. Otherwise when you set the relationship to null, it would incorrectly fail to clear the relation index attributes.
The manufactured 1.11 code has now been used to exercise all of the atomic data types for inserts and updates. There must be some incorrectly linked data somewhere in the database, or else there is a problem with reading multiple records the way I have the PostgreSQL npgsql code written right now. Further debugging is required.
Enough deletes have been processed that I'm comfortable the manufactured code is correct, but I seem to have a thornier problem to deal with -- either some RelationColumns aren't being read and their Prev/Next links cleared, or the update code is broken in some fashion and the setting to null is not taking effect. I'm suspicious of a bug in the loader for the RelationColumn, because I can't think of any other way that RelationColumn instances could be created without a correct/retrievable RelationId attribute and corresponding scoping relation.
In particular, LinkedList instances are used instead of ArrayLists, because they're less expensive to grow while reading the SQL result set into buffer instances.
Also, this way we know that the elements of the final list returned to the caller includes the proper subclasses of buffers in the case queries for table objects that have subclasses.
I'm not entirely sure whether this will fix my problem yet -- I'll be resuming the debug of the 1.11 PostgreSQL database reader shortly. It doesn't seem to be fetching all the rows that I know are in the database. The initial load/insert to the database and the update statements work fine, but the readers need some debugging.
In particular, I noticed this when I discovered that the RelationColumn elements of a Relation only had one element, when I know very well that many of the relationships in the application model being tested have multiple columns.
The read implementations for duplicate records were not using the proper SortedMap type signature. This has been corrected.
In order to prevent concurrent update exceptions, the maps returned by the TableObj read() methods are now independent copies of the internal cache maps rather than the actual internal maps.
This will slow processing down significantly, but it will make working with the resulting code much, much easier.
GEL support for the NumberDef.Digits and NumberDef.Precision attributes has been added.
The 1.10 version now produces a clean-running database creation script set for PostgreSQL.
The MssCF integration layer was incorrectly treating all sub-object relations referring to duplicate indexes, which is invalid (although very common.) The appropriate singleton Reference and HasReference verbs are now produced and integrated in addition to the IterateSuffix verbs that were previously produced. MSSBam20 produced by 1.11 now compiles clean.
There were several unique indexes in the MSSBam111 and S1Bam20 models which were not properly flagged as such by their definition attributes. Oops.
But at least it's readily apparent there is a modelling problem when you're working on code to resolve a unique name lookup and the interface says it returns multiple instances in a SortedMap.
Oops. Forgot to edit a Name to a Description during a copy-paste-edit.
There are some new attributes that have to be added to the 1.10 and 1.11 SAX parsers for the MSSBam models. I've added Description with this release, but the 1.11 model includes several other attributes that will have to be applied as well after the Description support is brought forward.
The PostgreSQL database creation scripts are now compliant with the 2000 character limit on rule bodies imposed by MSS Code Factory 1.11.
In order to support multi-user access to most relational databases, it is necessary to use the "FOR UPDATE" clause to refresh and lock an instance when initiating an edit.
The only database I know of that doesn't use "FOR UPDATE" syntax is Microsoft SQL Server. I'll have to implement soft locking or completely rework the code to use whatever scheme is supposed to be used to achieve concurrency with SQL Server when the time comes.
Just because SQL Server is based on Sybase ASE 10 does not mean it's been a stagnant database by any means.
The 1.11 release imposes a 2000 character limit on rule bodies, so the shared 1.10 rule base has been updated to comply with that restriction.
The 1.11 release is imposing a 2000 character limit on rule bodies instead of the more generous 8000 allowed by 1.10. The core Java rules have been updated to comply with this restriction, and are successfully loaded in order to manufacture S1Core20.
Next I need to work through the additional rules that are brought in when manufacturing S1Bam20.
The 1.9 production rule snapshot has been taken and refactored as the 1.10 rule base. The C# support has been pruned for now.
The engine has been redirected to search the packaged cartridge-1.10 directory in the jar file instead of 1.9.
The references to v1_9 in the rules have been updated to v1_11.
This build successfully manufactured the 2.0 S1Core and S1Bam 2.0 without displaying error messages or raising exceptions.
I will do a test compile of the code as well, but once that's done, I'll freeze 1.9 and bring forward the Java and PostgreSQL cartridges. I'm going to prune the rule tree down to the Java and PostgreSQL components that are currently my focus, then I'll bring forward the other packages one at a time as I find the time to work on them.
I need to focus on the JEE 6 server cluster that I envision as the hub of application clients running anywhere a JVM or .Net host can run. I'd also like to implement ISO C++ 11 support, but there is plenty of time for that -- the compilers aren't ready yet, apparently, though good progress is being made.
Yes, I will be counting on WSDL to provide the service methods.
The 1.9 MSSBamCF and MSSBamBLObj manually edited code has been brought over to 1.10 and the initial package changes and such have been applied. There are still a couple dozen errors to be fixed, but it's in pretty good shape for an hour's effort.
This release produces clean compiling code for 1.10, although the code has not been tested yet.
I already know the Blob implementations won't persist properly because I haven't implemented the "real" PostgreSQL/JDBC insert/update code yet.
All the Java code clean compiles now except for the Number attributes. I even stubbed in some temporary code for inserting and updating Blobs that treats them as Base64 strings, though that will blow up in my face as soon as I try to execute that code during testing because it is not the way you are supposed to do so.
BigDecimal is now used for Number; BigInteger is used for UInt64.
1.10 now weighs in at 954,255 lines.
Blob columns are now implemented as byte arrays. I had not been aware that the SQL Blob type was a binding buffer for JDBC, not a value wrapper like UUID.
org.apache.commons.Codec is now required by builds in order to implement Blob RFC encoding and decoding.
The PostgreSQL integration layer fetches Blobs, but I need to figure out how to do inserts and updates of Blobs yet.
There were 7,415 errors on Wednesday night, which is now down to 90. So 7,325 errors have been fixed since then.
CFLib wasn't on the build path for my test build of 1.10, which caused a lot of errors.
Once I added java.sql.* to the import list as well, the error count went down to 90 for the test build of 1.10.
java.sql.Blob does not implement compareTo( Blob obj ), so I'll have to figure something out for the object buffer comparators.
I need to refactor the references to getQuotedBlob() as getQuotedString().
BigDecimal colVal = resultSet.getString( idxcol )
BigDecimal colVal = resultSet.getBigDecimal( idxcol );
double colVal = resultSet.getString( idxcol );
double colVal = resultSet.getDouble( idxcol );
I also need to implement:
public UUID SchemaPg8Schema.convertUuidString( String value );
public String SchemaPg8Schema.getNumberString( BigDecimal value );
public String SchemaPg8Schema.getQuotedString( Blob value );
public String SchemaPg8Schema.getQuotedString( UUID value );
Finally, I need to catch and rethrow SQLException for some of the Blob accessors, like length().
The latest 1.9.3273 produces code with 7,415 errors. However, now I'm down to having to actually look at the errors to fix them, as I've finished the initial skeletal support for the new data types and am ready to start debugging the rules.
The latest version of 1.9 now produces code with 7,848 errors, down from 21,000 or so last night. So I squished another 13,000 bugs today. It's getting grody in here underfoot with the insect carcasses. :P
There are now 948,086 lines of manufactured code for 1.10.
Note that CFCore is only being used as a manufacturing test case for 1.10. It will be compiled, but the manually created components of the 1.9 code base will not be brought forward to CFCore 1.10 as no one is ever expected to compile against the 1.10 code base.
The 1.10 CFCore and MSSBam models are starting out as straight-forward migrations of the 1.8 models to 1.9 syntax. You can diff the 1.10 model files with the 1.9 models from the 1.8 code base to see what you have to change to migrate your application models to use MSS Code Factory 1.9. The 1.10 runtimes will require the 1.9 CFLib and CFCore libraries. The 1.11 runtimes will use 1.11 CFLib and CFCore.
Technically there are a lot more XSD basic types to add, but my focus is on the types most commonly required by business applications in my experience, so when I say "basic", I mean the subset of types that are either implemented by common machine architectures or in very common use in the industry. I may add a 1.13 release to implement the remainder (URL/AnyURI, Byte, Duration, GDay, GMonth, GMonthDay, GYear, GYearMonth, HexBinary, ID, IDREF, IDREFS, Language, Name, NCName, NegativeInteger, NonNegativeInteger, NonPositiveInteger, NormalizedString, QName, and UnsignedByte.) Most of those types can be implemented by filtering Strings or contraining the existing basic intrinsic types, and I've never seen anyone use the G* types in practice. I can't really implement "Name" unless I change its name, or things will blow up big time (maybe I'll call it XName.)
I've also increased the size of SchemaDef.DbName to 12 characters to allow for MSSBam110 for the 1.10 models.
Next I'll change the data types of the new XSD type definition attributes to use the appropriate data types. This will provide a full-spectrum test case for 1.9 supporting the new XSD data types, as by definition, all the types will be exercised as optional attributes of their own definitions.
Once 1.10 is running properly using that test data and can persist a PostgreSQL database image of MSSBam 1.10, I'll be ready to shift gears to 1.10 itself. In essence, the only thing changing between 1.9 and 1.10 is the types used to implement the attributes of the new XSD types.
Then I will finally be able to create 1.11, which is 1.10 with self-referencing manufactured code for CFLib 1.11 and CFCore 1.11 support. That will be the next and final production release for the MSS Code Factory 1.x series.