Implement this method, and its counterpart on the server side as follows: This method checks log files on the server side that report the results of auditing previously submitted new records. To this end the server side should implement a system of making the relevant log files downloadable by clients who submitted new records. The result of auditing is either 'pass', in which cas the log file will contain the remote key value for the record, or 'fail' in which case the new record was refused for some reason. In the case of 'fail' there should probably be a system of codes that indicate the reason, eg 'duplicate record' or something.

ExternallyLinkedORM

for new records: go back to the server to check for foreign key references of other tables and optionally refresh these in the local cache
possibly, as a step towards handling insertion of new records: allow for new records to be inserted but to remain purely local, recognisable by null value in remote key field. These records will be ignored during the refresh event, ie they will not be updated or deleted at any stage.
possibly, include non-linked tables in the references table to indicate how these remotely linked cached data records relate to the local non-linked application data. Then upon deletion of records that are referenced by local tables the user should have a choice not to delete those records in order to avoid data corruption. These records can then also continue as purely local records even though stored in linked table. Alternatively, a separate table could be created for these purely local records.
rename the different refresh functions to 'update' 'insert' 'delete', separate out delete and insert at start of refresh event retrieve set of remote keys as these are used in all three
separate out the ALLDATA refresh alltogether
the update function can now run more than once for the same table during a refresh data event (eg during its regular update, but also in the case when a record is deleted in a table that is has foreign key references to). To maximise efficiency we could consider keeping an array with key values that have already been updated during the current refresh event, and before running another update check against this array. Alternatively, make the update function only ever execute once during any given refresh event, ie build up an array with key values and only if it is complete run the update event.

ExternallyLinkedORM::InsertLocalRecords()

split up the 'delete' and 'insert' events, which are currently both included in this function.
the get new records function should or could send a message to the server to get any records from table(s) that refer to this table and have a reference to the new record and the local cache for this referring table can then be updated accordingly

Logon

gather requirements and implement functionality

ExternallyLinkedORM::refreshLocalData()

implement the refresh thing as follows: distinguish between the 'refreshType' and the 'updateType'. Of 'refreshType' there are two: the 'regular' refresh event including only those tables that need refresh regularly; and the'all tables' refresh event. Of updateTypes there can be any number, one of which is the default update type. The dataset to be updated for each of these types is defined in the updatLocalDataRule object.
the delete and get new events can be combined into one event as the full set of keys is returned to the application by the remote server for the delete event. based on this it is easy to determine which records are not in the local cache and request them from the server.
think about the implications of deleting records that might be referenced by other tables. Deleting records in referenced tables should probably result in some kind of update event in table(s) that reference that table as foreign key values in the records that refer to records that are now deleted should have been updated in the DoR. In case of an ALLDATA update this would be taken care of as a matter of course, but not necessarily in update events that work with subsets of the data.

RetreatConfig

gather requirements and implement the class

StudentSearch

gather requirements and implement functionality

SysAdmin

gather requirements and implement the class

ExternallyLinkedORM::updateLocalRecords()

possibly make it optional to include the update rules of referenced tables currently this happens without choice. Can be done with a boolean flag in the references table.
the 'keystring' that is used for the update event has the side effect that records that have been deleted from the DoR will be permanently deleted from the cache during the update event. So the update event does more than just update. As records that are to be deleted are treated differently this should be changed. One way to do this is to get the keyset from the server and to trim the 'keystring' down to include only what's actually on the server. A current workaround is to do the 'delete' event before the 'update' event.

Documentation generated on Mon, 18 May 2009 11:22:23 +0200 by phpDocumentor 1.4.1