abstract class %Library.SwizzleObject extends %Library.RegisteredObject
Returns a %Status value indicating success or failure.
Internally, %Delete() initiates a transaction and then invokes the storage interface method %DeleteData(). If %DeleteData() succeeds, the transaction is committed, otherwise it is rolled back.
%DeleteId() is identical in operation to the %Delete() method except that it uses and Id value instead of an OID value to find an object. Refer to About Concurrency for more details on the optional concurrency argument. If no value for the concurrency argument is passed or the value passed is -1 then it will be assigned the value of the DEFAULTCONCURRENCY parameter as defined for the class.
This method synchronizes an entry from a %SYNC.SyncSet with the local database. The method is generated and should not be overridden by the user and there are no callbacks from this method. The return value of this method is a %Status value that indicates success or failure. Inputs to this method include an oref to a %SYNC.SyncSet object, a pointer to the entry in the SyncSet and the type of modification represented by the SyncSet entry. Modifications are of three types - insert a new object, update to an existing object, and delete an existing object. A parameter passed by reference allows the caller to receive an oref to the affected object in the local database.
An entry in a SyncSet corresponds to one object in the local database. It contains values for properties of the object and represents some modification to an object made in another database called the 'source' database. To synchronize the modifications made to the object in the source database it is necessary to repeat those modifications in the local database. The first task is to resolve the GUID that identifies the modified object with the local database. If the object exists in the local database and the type of modification, fileop, is a delete then the object is deleted from the local database and the status is returned to the caller. If the object does not exists in the local database and the modification is a delete then nothing is done and a success status is returned to the caller. For other modification types, inserts and updates, the object is opened if it exists or a new object created if it does not exist. It is to this object that modifications contained in the SyncSet are applied by copying each value from the SyncSet entry to the corresponding property. Property values are either literals or objects. If the value is a literal it is simply copied into the object. If the property is an object then the value is either a GUID or a link to an object that exists in the SyncSet. Object links are used to resolve references to other object values that have not yet been synchronized to the local database. If the value is a GUID then the value is resolved by resolving the GUID to an OID using the local database's GUID tables. If the GUID cannot be resolved then a new SyncSet entry is added to the end of the SyncSet and the pointer to that SyncSet entry is used to link the current SyncSet entry to the newly created SyncSet entry. If the property whose value cannot be resolved is a required property then the new SyncSet entry is a complete copy of the current entry, otherwise it is simply a partial entry containing the unresolvable values. For serial objects, there is no 'partial' sync so any failure to resolve a GUID or linked object must be treated the same as a required property.
Once all values from the SyncSet entry have been processed by either synchronizing them with the local object or deferring resolution through link creation an oref to the local object is returned to the caller. If the local object is an instance of a %Persistent class then it is also saved. Any failure reported by %Save is reported to the caller.