2014.10.20 Programmer's Notes

Chains require a number of changes to support them, and I'll be posting
builds as each step of the process is completed.  But until all the steps
are completed, the builds will produce "broken" code that results in object
deletion problems or worse, so I won't be making those the default downloads.
You should stick with SP4 until SP5 is released.

sp_create_table() has to be modified to establish the chain linkage.  After
the instance is created, it needs to be passed on to a new sp_linktail_table_by_suffix()
routine that updates the tail of the chain with a reference to the new instance,
and then updates the prev link of the new object to reference the tail.  If no
tail is present, the prev link remains null and nothing gets updated.  The
revision columns of both objects have to be updated as well.  Only the base
table with the revision column and the table containing the chain need to be
updated, but the rules will be rather complex to code as they need to flip between
versions that update two tables and versions that update one table, according to
where the chain linkages are defined.

The tail is identified by querying for an instance with the same container as
the new instance, but with a next link of null.  This code will all be going into
a new routine because the sp_create_table() code would become an obscene mess if
I tried to embed it in the existing routine.  Also, by making it a seperate routine,
subclasses of the instance can share the same link establishment routine instead
of having to embed the code into each and every subclass of the chain-defining
table.

Note that only one chain can be defined for an object hierarchy.  You may NOT
have multiple chains for the same object.

sp_delete_table() then needs to be modified so that it breaks the established prev
and next links before deleting the object instance.  Again, this will be done via
a subroutine, likely named sp_unlink_table_by_suffix().  This routine needs to lock the instances
referenced by the prev and next links before making any changes to the database.  Once
those locks are established, it rewires the prev instance's next link to reference the
next reference of the unlinking object, and the next instance's prev link to reference
the prev reference of the unlinking object.  Allowances have to be made for null prev/next
links of the unlinking object, and as with the sp_linktail_table_by_suffix() code, there has to be
consideration of whether one or two tables need to be updated.  The revisions of the prev
and next objects get updated by this operation.

The next thing I need are sp_moveup_table_by_suffix() and sp_movedown_table_by_suffix() routines, which relink
the object either one instance backwards or forwards in the chain.  Up to four objects get
updated by these routines, so they're going to be relatively complex.  I thought about
providing sp_movebefore_table() and sp_moveafter_table() implementations that would let an
instance "jump" in the chain, but I've decided against that for the sake of "simplicity" (not
that chains are going to be simple.)  Maybe someday I'll add those routines as well; I may
even change my mind before SP5 is released.  Who knows what urges will strike me.  Whenever
I do add such code, specifing a null as the referenced object for before/after operations
will allow for moving to the head/tail of the chain.

The client side cache code needs to be updated such that after a create operation the
referenced prev-instance is force-read to refresh it from the database.  The client-side
update code will be a little nastier, because it needs to track the prev/next links of the
instance *before* it is updated and refresh those instances as well as those reference by
the updated prev/next links of the instance.  Otherwise you'll have stale references in the client.

The client side caching code for deletes also needs to track the prev/next links prior to the
deletion of an instance, and force-read those objects after the deletion completes.

Note that I'm counting on the revisions to detect update conflicts so that the prev/next
links to be re-read are sane after the stored procedure returns, but no such presumptions
can be made about deletions, because the deletes intentionally ignore the revision conflict
detection as future-proofing for the chain code I expected to be working on some day.  Otherwise
the values of the result sets cursored by a delete-by-index could potentially be stale with
some databases and incorporated outdated revision values.  Rather than let such a possibility
creep up, I'd long ago decided to ignore revision checks in the delete-instance code of the
stored procedures.

New client-side interface and implementation methods for moving instances prev/next in the
chain have to be added as well, along with the table methods for invoking the stored procedures.

With the database stored procedures and the client side object and cache changes made, I'll
finally be ready to tackle the Swing GUI prototype changes.  The first thing to be done is
to add code that sorts the instances of a sub-element selection set by the chain links instead
of the default primary index key sorting that is done by the existing code.  Otherwise there
wouldn't be much point to allowing user-established instance ordering through chains, now
would there?

The menus for the element lists need to have Move Selected Up/Move Selected Down menu
items and actions added to them.

With the chains established and modifiable through the GUI, it will be time to tweak the GUI
a little further so that the prev/next references of an instance no longer show up in it's
Attribute panels as reference lookups.  I don't want people to be able to mess with the linkages
manually, because they could corrupt the chain data if they did so.

I think that's about it.  At that point I should be ready for Service Pack 5.