MidCOM 2.5 Datamanager Rewrite Attachment Handling

1. Problem description
1. The Attachment GUID
2. The Attachment Files
2. Approaches to a solution
1. 1. Have no attachment undo
2. 2. Have attachment undo

This is a MidCOM 2.5 Development Technical Note covering the Datamanger Rewrite. Everything written here is subject to change without notice.

Author's Note: The problems outlined here are also valid for parameters added outside the regular parameter storage target.

Problem description

The handling of attachments within the new Datamanager requires special care. Reason for this is the fact that attachments are not part of the regular content object. They have their own GUID (which is the first problem) and they have a file which is attached to them. Both facts are problematic.

The Attachment GUID

The GUID is used in all cases for referencing the attachment in question. Specifically, it is used for attachment serving in the URL on the attachment server host.

This means, that any solution which deals with attachments must do so transparently to the GUID, especially when temporary attachments are needed in the system. Two special cases apply here:

When uploading, the newly created attachment records have to be stable from the time of the upload already, so that it can be used during linking already. Obviously, the attachment records created by the system will have to be moved to the real object in question, instead of duplicating them.

The Attachment Files

Similarily to the GUID problem, the attachment files itself have to be available from the start, so that the regular attachment handler is able to serve them normally.

This is critical in places where you replace or update existing attachments. This will most probably not be easily doable, meaning that file replacements might not be undoable.

Approaches to a solution

1. Have no attachment undo

This will be the first implementation approach. The attachment related data types will access a Midgard storage object directly in all cases. For newly created object, objects are attached to a temporary object which is used by the datamanger until the user choses to actually save the object.

Neccessarry for this are a number of stub implementations on the storage layer classes, which provide access to the attachment storage (example calls):

$attachment = $storage->create_attachment($name, ...);
$attachment = $storage->get_attachment_by_guid($guid);
$attachments = $storage->list_attachments();

Attachments objects retrieved through the create/list calls can be used normally, they already point to the "encaspulated" objects where neccessary.

When editing existing objects, the calls are redirected to the actual content object unconditionally.

When creating new objects, things are different. The DM will have a temporary object in its own table, and attachments will be created / listed there. When the create cycle completes, the storage locations of all attachments are automatically moved to the new content object by changing their object link properties.

2. Have attachment undo

In this case a complete layer between the attachment handling has to be built, which leaves the orginal content object alone until the user saves the object.

This means, that when changing existing attachments, temporary files have to be created which are then moved to the real object only if the user does not cancel editing.

Due to the complexity of this, it will not be implemented in the first stage of the Datamanger rewrite. The full encaspulation of attachment operations through the storage layer should make adding this functionality not too hard at a later time.