From:
To:
Implement the record_load method on a NamedInput.
This first implementation of the namedInput makes some assumptions about what can be loaded into a given instance:
The input can only take one type of objectwe get this by defaultThe input can only hold one object at a timewe get this by defaultAn object cannot be loaded if it is already loaded somewhere elsewe get this by default
The lowest level of implementing the load/unload methods is an append-only log of all load operations performed.
This is the purpose of the named_input_processes.load_{object_type_table} tables.
A load operation record currently details:
- what input the load was performed on
- which object was loaded
- when the object was loaded
- why the object was loaded
- the corresponding unload record
The only limitation placed on the load operation log is that load operations cannot be logged multiple times. This requirement is implemented as a unique constraint on the set (input_id, loaded_object_id, unload_id). Practically, this means that, in order to record a new load operation of a given (input, object) pair, the first load operation record must be updated with a corresponding unload operation record.
I have now implemented the low-level record_load method on the generic NamedInputLoad model class.
I am inclined to consider the record_unload method on the namedInputUnload model class, as it exists as a “reversal” of a load record, and I need to decide at which level this “reversal” is understood. i.e. does the namedInputLoad instance “know” it has been unloaded? According to the data-model, it does “know” at least in the sense that there is an FK from load_{input_table} to unloads. This is a side-effect of the load tables being a class of tables meaning the relationship is forced to originate from it due to the strictness of SQL relationships requiring one concrete table instance relates to one other concrete table instance, with no dynamic allocation. As a result of this, the correct implementation is to trace this relationship from NamedInputLoad to NamedInputUnload. However, Django does cover for us with the dynamic allocation of “backwards” relationships, enabling the API we desire, which originates from the unload to the load.
In fact, because of this, we can offer a full bidirectional API leaving the action up to the developer.
The result of all this is to encourage me to first implement the low-level record_unload API before implementing load at the higher level.
Having now implemented the low-level load and unload interface, it is time to implement this on the NamedImput.
The ‘shape’ of the process is dynamically determined by the ProcessType defined at runtime. Importantly, this means there is no governance of the structure of a given process ahead of time.
Key
The ‘shape’ of a process is defined at runtime by the
ProcessType, there is no governance over this ‘shape’ from DB records.
I am implementing the following action in the process-model API: input.load(object).
And given the way the implementation has fallen out, it is trivial to extend to multi-type inputs, and trivial to extend to read-only vs write inputs. However, extending to inputs beyond just a single space is non-trivial.
Having considered this through, I am going to keep the load constraints minimal, and leave constraining up to the application developer.
I have now implemented load, unload, and state for NamedInput. state just returns a tuple of the currently loaded objects.
There is more to come for this interface, but this is a sufficient bare-minimum.