2014.09.28 Programmer's Notes

Service Pack 1 was pretty much a seat-of-the-pants development
of new functionality with additional testing of that functionality.
I'd always had the goal of using 1.11 to create some sort of GUI
for CFBam 2.0, and this was a big step forward on the route to that
goal.

Service Pack 2 will follow along in the same vein, enhancing the
Swing prototype GUI until it is capable of properly editing a CFBam 2.0
specification model, including support for Chains that are used to
enable user-determined ordering of objects in the sub-element lists.

There are a few constructs I'm going to need to add to 1.11 in order
to support that functionality.

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.

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.

At this point, the only other piece of functionality I think I'll
need is to code the rules around the Chain specifications that I
added to a Table a long time ago.  The Chain specifications will
add code to identify the head and tail of the chain as the Prev/Next
links owned by the Container of the object which have a null reference.
There is a good chance I'll have to enhance the model specifications
to properly establish those virtual relationships.  The simpler part
of implementing Chains is automatically establishing the Prev/Next
relationships in the SAX XML parser code; I've done something similar
in the hand-coded 1.11 SAX parser, and the code required isn't very
complex, though it does update the Prev object during the load process.

Deletes will require significant enhancements once Chains are established
by that "phase 1" implementation of Chain support.  If an individual
object is being deleted, the chain has to be broken and mended between
the Prev/Next objects referenced by the deleted object, so that you can
delete the instance using a single operation.  This will result in stale
references in the cache, so I may need to create a new delete result set
that returns the Prev/Next objects automatically instead of just a success
flag, such that the client can automatically update the stale references.
That should suffice for deleting an object from the CFBam 2.0 GUI prototype.

When deleting by the index that identifies the container of a chained object,
the delete-by-index will act a little differently to reduce the number of
updates performed in the database and speed up the process a little.  What
that process will do is clear the Prev/Next links of the sub-objects with
a multi-record updated, and then invoke the individual deletes.  So if you have
n sub-objects, it will require n+2 database operations to perform the delete,
whereas if you were to rely on repeatedly deleting the head (or tail) element
of the chain iteratively, you would be performing (n*2)-1 operations.

Ideallly I'd like to enhance the implementation rules of the DeleteDependancy
specifications to rely on those chained delete operations, but to perform them
on entire groups of containers at a time.  I haven't given much thought about
how I'd do that, but if I can do so, it should speed up the delete of complex
objects by a rather large amount of time, probably in the 90% reduction range
for complex objects with any significant number of sub-elements.

Note that for Service Pack 2, I'd only be using CFDbTest 2.0 enhancements
using these new constructs to exercise the resulting code.  It takes too much
time to manufacture CFBam 2.0 to use it for testing.  Ideally near the end of
Service Pack 2 development I'll use those new enhancements to flesh out the
CFBam 2.0 model, producing a GUI that can be used to fully edit a business
application model specification.  Once that capability is realized, I'll
consider Service Pack 2 to be ready for release.

Which brings me to Service Pack 3, which will not see significant enhancements
to the 1.11 specifications or rules, but rather to the 2.0 models.  I need to
bring up the 2.0 models to the point where I can *use* them with CFBam 2.0 to
code a replacement for 1.11.  I'll also want to code a migration process for
bringing the 1.11 rules forward to the new 2.0 specification syntax, rather
than trying to hand-migrate the rules.

After that process is complete, I'll work on customizing the CFBam 2.0 GUI
to provide support for importing and exporting models from the database,
invoking the manufacturing engine, and creating log files of the resulting
manufacturing process.

My final task for Service Pack 3 will be to customize the CFCore 2.0 code
such that the CFBam 2.0 rule base can produce CFBam 2.1, which will run on
CFCore 2.0 instead of CFCore 1.11 as CFBam 2.0 will.

That means that Service Pack 3 will be the end of the 1.11 development and
enhancement process, capable of producing generic complex object applications;
a goal which I haven't quite achieved to date.

When Service Pack 3 is released, I'll be shifting to the development and
enhancement of the 2.0 code base with the goal of producing 2.1, which will
run on CFCore 2.0/2.1 instead of 1.11 as the 2.0 models currently do.

When 2.0 is ready for release, I'll have come full circle to manufacturing
a full engine from the 1.11 rule base, whereas the 1.10 release only
manufactured the *core* of the 1.11 engine, leaving me with over two
years of custom coding to be done.

Initially 2.0 will be relying on the manufactured GUI for it's implementation.
Another goal I have for 2.1 is to create a greatly enhanced custom *graphical*
GUI, potentially shifting from Swing to some other technology.  Perhaps Android.
I'd love to be able to use a pen-oriented device such as Samsung's tablets to
edit a BAM with a sketch-and-scribble interface.  I've wanted to have such a toy
for a long time, suitable for "taking notes" in business design meetings and capturing
the details on the fly.

Hey, a guy can dream, can't he?  Maybe by then I'll be able to *afford* a Samsung
tablet.  My budget is kind of tight for such things right now, but I figure it'll be
at *least* a year or two before I'm at that point so I'll be able to save up. :)