System and method for sandboxing

Abstract

A system include at least one programmable processor (13) and at least one machine-readable medium (15) storing instructions that, when executed by the at least one programmable processor (13), cause the at least one programmable processor to permit at least one client (11a, 11b) to access a computing environment (6) comprising a plurality of components (COMP(n,mn)). Each component (COMP(n,mn)) stores record data. The instructions, when executed by the at least one programmable processor (13), also cause the at least one programmable processor (13) to permit the at least one client (11a, 11b) to generate a sandbox instantiation (8) of the computing environment (6) within a main instantiation (7) of the computing environment (6) or within a previously generated sandbox instantiation (8) of the computing environment (6) to which the at least one client (11a, 11b) has access. Each sandbox instantiation (8) has a creation time. A read query in a given sandbox instantiation (8) returns record data from a timeline of the given sandbox instantiation (8) which matches the read query.

Description

[0001] System and method for sandboxing Field The present invention relates to systems, data structures and methods for generating and manipulating sandboxes in a computing environment. Background A sandbox is a testing environment separated from a main computing environment. Sandboxes are used to isolate the main computing environment from code changes and data / database changes made in the sandbox. This is used by organisations such as businesses to test changes without affecting their main, day-to-day, computing environment. Prior sandboxing platforms typically operate based on a static snapshot of the data in the corresponding main computing environment (for example see https: / / docs.aws.amazon.com / AmazonRDS / latest / UserGuide / USER_CreateSnapshot. html), or using synthetic data intended to be representative of regular operation. Summary According to a first aspect of the invention, there is provided a system including at least one programmable processor and at least one machine-readable medium storing instructions that, when executed by the at least one programmable processor, cause the at least one programmable processor to permit at least one client to access a computing environment comprising a plurality of components. Each component stores record data. The instructions, when executed by the at least one programmable processor, also cause the at least one programmable processor to permit the at least one client to generate a sandbox instantiation of the computing environment within a main instantiation of the computing environment or within a previously generated sandbox instantiation of the computing environment to which the at least one client has access. Each sandbox instantiation has a creation time. A read query in a given sandbox instantiation returns record data from a timeline of the given sandbox instantiation which matches the read query. The record data from the timeline of the given sandbox instantiation consists of: ^ record data of the given sandbox instantiation which is valid up to a time of the read query; and ^ in a case where the given sandbox instantiation is a direct descendant of the main instantiation, record data of the main instantiation which was valid up to the creation time of the given sandbox instantiation and which is not superseded by record data of the given sandbox instantiation; ^ in a case where the given sandbox instantiation is descendant from the main instantiation via a sequence of one or more antecedent sandbox instantiations: o record data of the main instantiation which was valid up to the creation time of an earliest antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations and which is not superseded by record data of the given sandbox instantiation or record data of a sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and o for each of the sequence of one or more antecedent sandbox instantiations, record data of that antecedent sandbox instantiation which is not superseded by record data of the given sandbox instantiation or record data of a subsequent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations and which was valid up to the earlier of: ^ the creation time of the next antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and ^ the creation time of the given sandbox instantiation. Record data may match the read query if that record data matches one or more filters defined in the read query. The one or more filters may be user specified via the at least one client, may be predetermined, or may be a mixture. The one or more filters may depend, at least in part, on a context of the read query. The read query may include a filter to remove record data that has been indicated or flagged as deleted. In a case that a second sandbox instantiation is generated within a first sandbox instantiation, the second sandbox instantiation may be described as being a direct descendant of the first sandbox instantiation, and additionally (and equivalently) the first sandbox instantiation may be described as being a direct antecedent of the second sandbox instantiation. The concepts of descendent and antecedent sandbox instantiations may span multiple generations. For example, if a third sandbox instantiation is generated within the second sandbox instantiation, then the third sandbox instantiation may be described as a descendent of the first sandbox instantiation as well as being described as a direct descendent of the second sandbox instantiation, whilst the first sandbox instantiation may be described as an antecedent of the third sandbox instantiation and the second sandbox instantiation may be described as a direct antecedent of the third sandbox instantiation. In a case where a fourth sandbox is generated within the third sandbox instantiation, the fourth sandbox instantiation may be described as being descendant from the main instantiation via a sequence of one or more antecedent sandbox instantiations including, in order, the second sandbox instantiation followed by the third sandbox instantiation. In a case where a fifth sandbox instantiation and a sixth sandbox instantiation are not related as descendant / antecedent, a sandbox which is an antecedent of both the fifth and sixth sandbox instantiations may be described as a common antecedent of the fifth and sixth sandbox instantiations. A read query in the main instantiation and / or any sandbox instantiation may additionally return data from any number of sources which are accessible to the computing environment other than the plurality of components. Data from a number of sources which is accessible to the computing environment other than the plurality of components may be in the same format as the record data, or may be in a different format to the record data. For example, a read query in the main instantiation and / or any sandbox instantiation may additionally return data (in the same or a different format to the record data) from one or more conventional databases communicatively connected to, or forming part of, the computing environment. At each creation time along the timeline of a given sandbox instantiation, only record data of the sandbox instantiation corresponding to that creation time may be on the timeline. For example, in the preceding example of the first to fourth sandbox instantiations, at the creation time of the first sandbox instantiation, record data of the first sandbox instantiation which corresponds to the creation time may be on the timeline of the fourth sandbox instantiation. However, record data of the main instantiation which corresponds to the creation time of the first sandbox instantiation may not be on the timeline of the fourth sandbox instantiation, although record data of the main instantiation corresponding to just before the creation time of the first sandbox instantiation will be on the timeline of the fourth sandbox instantiation. In relation to the timeline of a given sandbox instantiation, record data of an antecedent instantiation (whether the main instantiation of one of a sequence of one or more antecedent sandbox instantiations) is superseded by record data of a descendent sandbox instantiation (which may be the given sandbox instantiation) if both sets of record data correspond to (or represent) the same object / element. In this way, data corresponding to an object / element may be changed in a sandbox instantiation without affecting the record data corresponding to (or representing) that object / element in the main instantiation or any antecedent sandbox instantiations. In the context of a read query, the given sandbox instantiation may alternatively be referred to as an “originating” or “active” sandbox instantiation. Processing modifications made to a component of the plurality of components may use a copy-on-write process. A modification may include addition of record data. A modification may include deletion of record data. A modification may include replacement of record data. A modification may include changing of the structure of a component and / or record data stored therein. In a case where a modification is made in a given sandbox instantiation (alternatively an “active” sandbox instantiation) to given record data from the timeline of the given sandbox instantiation which is derived from the main instantiation or which is derived from an antecedent sandbox instantiation, the given record data is not modified in the main instantiation or antecedent sandbox instantiation, and new record data is added to the given sandbox instantiation to supersede the given record data on the timeline of the given sandbox instantiation. In a case where the modification of the given record data is a deletion, the given record data may not be removed from the corresponding component. Instead, new record data may be added to supersede the deleted given record data in the given sandbox instantiation. The new record data may be valid from the time of deletion and may be flagged (or tagged, or otherwise labelled) as deleted. In a case where the given record data to be deleted in the given sandbox instantiation is inherited from the main instantiation or from one of the sequence of one or more antecedent sandbox instantiations, new record data corresponding to the deleted record data may be added to the given sandbox instantiation and flagged (or tagged, or otherwise labelled) as deleted from the time of deletion. The new record data supersedes the deleted given record data within the given (or “active”) sandbox instantiation (which may remain valid in the main instantiation and / or other sandbox instantiations) on the timeline of the given sandbox instantiation. Replacement or updating of given record data may not involve removal of the given record data from the corresponding component. In a case where the replaced / updated given record data is from the given (or “active”) sandbox instantiation, the replaced / updated given record data may be marked as not valid from the time of replacement, and the new record data added to the given sandbox instantiation may correspond to the replaced / updated data which is valid at and after the time of replacement. In a case where replaced / updated given record data is from the main instantiation or from the sequence of one or more antecedent sandbox instantiations, the new record data corresponding to the replaced / updated record data supersedes the given record data on the timeline of the given sandbox instantiation (according to the definition of the timeline of the given instantiation). Alternatively and optionally, a first new record data corresponding to the replaced / updated given record data may be added to the given sandbox instantiation and marked as not valid from the time of replacement, whilst second new record data may also be added to the given sandbox instantiation corresponding to the replaced / updated data, and which may be valid at and after the time of replacement. Each component may include metadata. Record data may include metadata. At least some of the metadata may include, or take the form of, record data. In a case where a given component of the plurality of components is configured to generate one or more outputs, metadata of the given component may store one or more output suppression flags corresponding to any or all of the one or more outputs. In a case where the given component of the plurality of components stores one or more output suppression flags, the corresponding outputs generated by the given component in a sandbox instantiation may be suppressed or re-directed. Output suppression flags may apply to the given component in any sandbox instantiation. In other examples, a user having access to the given component may be permitted to selectively enable or disable particular outputs in a given sandbox instantiation by setting or removing corresponding output suppression flags. The one or more outputs may include, for example, outputs generated by record data which includes, or takes the form of, executable computer code stored in the corresponding component. Examples of outputs from components which may be suppressed may include, without being limited to: ^ An output in the form of a message for sending to a recipient external to the computing environment; ^ An output in the form of a control signal for controlling one or more devices, actuators, peripheries and so forth, which are communicatively coupled to the computing environment; ^ An output in the form of a command or request to modify record data of one or more other components of the plurality of components. Suppressing or re-directing one or more outputs corresponding to output suppression flags may include, or take the form of, adding those outputs to an output queue. The output queue may be stored in the given component or in a different component of the given component. Suppressed or re-directed outputs generated in a given sandbox may be held in the corresponding output queue unless and until the given sandbox is merged with the main instantiation, or merged with a different sandbox instantiation in which the one or more outputs are not flagged by output suppression flags. The computing environment may also include one or more global components. Each global component may store global data. A read query in a given (or originating / active) sandbox may return a union of matching global data and the record data from the timeline of the given sandbox instantiation which matches the read query. Each global component may comprise metadata. The metadata of a global component may have the same structure as metadata of a component of the plurality of components. Global data may be structured the same as record data. Global data may be structured differently from record data. Any modification of global data of a given global component may be visible to every sandbox instantiation which has access permission to the given global component. Access permissions of different users to components and / or record data may be manged using known user access control methods. Metadata of a given global component may specify whether or not the corresponding global data may be modified within one, a subset, or all of the sandbox instantiations. A given global component may store a first set of global data which may be modified within one, some, or all of the sandbox instantiations, and a second set of global data which may only be modified within the main instantiation. One or more of the components may store global data in addition to record data. A read query in a given (or originating / active) sandbox may return a union of matching global data and the record data from the timeline of the given sandbox instantiation which matches the read query. In a case where a component stores record data and global data, global data may be indicated using metadata flags. Global data stored in a component may include any or all of the features of global data stored in a global component described herein. In response to changing a structure (in some contexts called a “schema”) of a given component of the plurality of components within a given (or active) instantiation and / or changing a structure (or schema) of record data of the given component of the plurality of components within the given instantiation, a new version of the given component may be generated at a version update time and associated with the given instantiation. In a case where the version update time and the given (or originating / active) instantiation are from a timeline of a given sandbox instantiation, a read query in the given sandbox may return record data of the new version of the given component. In a case where the version update time and the given (or originating / active) instantiation are not from the timeline of the given sandbox instantiation, a read query in the given sandbox may returns record data of the given component (i.e. the older version). The given (or originating / active) instantiation may be the main instantiation or any sandbox instantiation. The association of the given instantiation with the new version of the given component may be stored in metadata of the new version of the given component. The structure of the given component of the plurality of components and / or the structure of record data of the given component may be modified within the main instantiation or within a sandbox instantiation. The new version of the given component may also store a record of which instantiation (main or which sandbox) it was generated within. A given time, for example the version update time, may be within a timeline of a given sandbox if a hypothetical record data, which is assumed not superseded and valid at the given time, would be included in the timeline of the given sandbox. In other words, sandbox instantiations corresponding to timelines including the modified component / data record structure may access the new version, whereas sandbox instantiations corresponding to timelines where the component or record data structure was not modified may continue to access the previous version. Both versions may exist in parallel for different sandbox instantiations. Record data may continue to be added or otherwise modified in the previous version of the component, for example, within sandbox instantiations for which the version update time is not within the respective timeline. The at least one client may be further permitted to merge a given (or "source") sandbox instantiation into (or “with”) a target instantiation which is the main instantiation or a different sandbox instantiation which is not the given sandbox instantiation. Merging the given (or source) sandbox instantiation into the target instantiation may include modifying record data of the target instantiation based on comparing record data from the timeline of the given sandbox instantiation with: ^ in a case where the target instantiation is the main instantiation, record data of the main instantiation which is valid up to a time of the merge; ^ in a case where the target instantiation is the different sandbox instantiation, record data from the timeline of the different sandbox instantiation. Modifying record data of the target instantiation may include one or more of adding record data, replacing record data, combining record data and / or deleting record data. Modifying record data of the target instantiation may include any combination of: ^ adding record data from the timeline of the given (or source) sandbox instantiation; ^ replacing record data from the target instantiation (i.e. from the main instantiation or from the timeline of the different sandbox instantiation) with record data from the timeline of the given (or source) sandbox instantiation; ^ combining record data from the target instantiation (i.e. from the main instantiation or from the timeline of the different sandbox instantiation) with record data from the timeline of the given (or source) sandbox instantiation; and / or ^ deleting record data from the target instantiation (i.e. from the main instantiation or from the timeline of the different sandbox instantiation) which is absent from the timeline of the given (or source) sandbox instantiation. In any of the preceding cases, modification of record data in the target instantiation (i.e. from the main instantiation or from the timeline of the different sandbox instantiation) may be made using the copy on write processes described herein. Merging the given (or source) sandbox instantiation into the target instantiation may include determining the existence of any conflicts between record data from the timeline of the given sandbox instantiation and: ^ in a case where the target instantiation is the main instantiation, record data of the main instantiation which is valid up to a time of the merge; or ^ in a case where the target instantiation is the different sandbox instantiation, record data from the timeline of the different sandbox instantiation. The system may be configured, in response to detecting one or more conflicts, for each conflict: ^ to resolve that conflict according to pre-set rules; or ^ to prompt the at least one client to resolve the conflict. The timeline of the different sandbox instantiation may be evaluated at the time of the merge. A conflict may exist if one or more of the following conditions apply: ^ record data from the timeline of the given (or source) sandbox instantiation has been modified or deleted, but corresponding valid record data from the main instantiation, or the from the timeline of the different sandbox instantiation, has been modified after a time when the timeline of the given (or source) sandbox instantiation diverged from the main instantiation or the timeline of the different sandbox instantiation; ^ record data from the timeline of the given (or source) sandbox instantiation is to be merged, but the main instantiation, or the timeline of the different sandbox instantiation, do not include corresponding record data because it was deleted after the time when the timeline of the given sandbox instantiation diverged from the main instantiation or the timeline of the different sandbox instantiation; and ^ in a case where record data corresponds to a component of the plurality of components which is configured to enforce one or more rules on the record data is stored, and in a case where record data from the timeline of the given (or source) sandbox instantiation would contravene a rule of the one or more rules if merged into the target instantiation. The preceding list is not exhaustive, and any number of additional conflict conditions may be defined by a user or administrator of the computing environment. Examples of rules which a given component may be configured to enforce on record data may include, for example, requiring uniqueness of record data within each instantiation, requiring numerical values within respective ranges, requiring record data to have a particular format, and so forth. A rule enforcing uniqueness may be applicable to record data from the main instantiation and to record data on the timeline of every sandbox instantiation. However, since different sandbox instantiations may see different record data on the respective timeline, record data need not be unique in a component overall. The pre-set rules may be fixed. The pre-set rules may be user editable. For example, a user of the at least one client may be prompted to set conflict resolution rules, or to select / adapt from a number of template conflict resolution rules, at the time of initiating the merge or at the time of generating the given sandbox. The user of the at least one client may be prompted for input to resolve one or more conflicts during the merge. The user of the at least one client may be prompted for input to resolve one or more conflicts upon requesting the merge but before starting the merge. In other words, the system may check for conflicting record data and require the user of the at least one client to resolve all conflicts before commencing and / or completing the merge. Resolving a conflict may include one or more of (without being limited to): ^ using the record data from the given (or source) sandbox instantiation to replace corresponding record data from the target instantiation (i.e. from the main instantiation or from the timeline of the different sandbox instantiation); ^ keeping record data from the target instantiation (i.e. from the main instantiation or from the timeline of the different sandbox instantiation); ^ deleting record data from the target instantiation (i.e. from the main instantiation or from the timeline of the different sandbox instantiation); ^ generating new record data based on corresponding record data from the given (or source) sandbox instantiation and the target instantiation (i.e. from the main instantiation or from the timeline of the different sandbox instantiation); ^ in the case where the at least one client is prompted to resolve the conflict, using new record data input via the at least one client in response to the prompt. The at least one client may also be permitted to re-base a given (or source) sandbox instantiation to which that at least one client has access, relative to a base instantiation. The base instantiation may be the main instantiation or a different sandbox instantiation which is not the given sandbox instantiation. Re-basing a given sandbox instantiation may include generating a new sandbox instantiation within the base instantiation and merging the given sandbox instantiation into the new sandbox instantiation. The new sandbox instantiation may be the target instantiation for the merge. The at least one client may select the base instantiation, either before or at the time of the request to re-base the given (or source) sandbox instantiation. Record data belonging to a given sandbox instantiation may be deleted (i.e. the associated computer readable being wiped, allocated as available and so forth) provided that record data is not valid in any active sandbox instantiations which are descendants of the given sandbox instantiation. The record data of each component may include at least one data item. Each data item may include: ^ data payload; ^ a data identifier; ^ a sandbox identifier; ^ a start time; and ^ an end time. The data item may be valid at or after the start time and before the end time. Ongoing validity of a data item may be denoted by omitting the end time or by setting the end time to a predetermined ongoing validity value. The predetermined ongoing validity value may have a value such as, 0, -1, NaN and so forth. Here, NaN represents a value of “Not a Number”, commonly used in computer systems when output of a numerical evaluation is undefined. For example the output of dividing by zero. The ongoing validity value may be set to any value not needed to define conventional and practical times. For example, the ongoing validity value could be negative, or could be set to a maximum value that can be stored in given variable type in a particular computer system (for example, the maximum value in a 32-bit or 64-bit computer system). The data identifier of a data item may also be part of the data payload data of that data item. The data identifier of a data item may be derived based on all, part of, the data payload of the data item. Membership of the main instantiation may be identified by omitting the sandbox identifier. Membership of the main instantiation may be identified by using a predetermined value of sandbox identifier to denote the main instantiation such as, for example, 0, NaN and so forth. A predetermined value used to denote the main instantiation may be reserved and may be prohibited from use to denote a sandbox instantiation. Each data item may take a form such as, for example, a row of a table, an entry in a database comprising a specific number of fields, and so forth. Each data item may also include a global data flag denoting whether that data item is global data. In a case where all data items of a component are flagged as global, then that component may be a global component. In a case where one or more individual data items of a component are flagged as global, those one or more individual data items may be global data, and may also be described as global data items. Global data items which match a read query and to which the at least one client has access may be returned in response to a read query within any given (or originating) sandbox instantiation. Alternatively, instead of flagging global data within individual data items, global data may instead include, or take the form of, combining one or more data items with one or more corresponding metadata flags stored in the metadata of the corresponding component. A new data item generated in response to a change made to a given component of the plurality of components within a given (or active) sandbox instantiation may have a sandbox identifier corresponding to the given sandbox instantiation, and a start time corresponding to the time of the change. When the change is made in the main instantiation, the sandbox identifier corresponding to the new data item may be omitted or set to the predetermined value denoting the main instantiation. In relation to record data from the timeline of the given sandbox instantiation, record data of the given sandbox instantiation which is valid up to a time of the read query may corresponds to, for each component of the plurality of components, data items which have a sandbox identifier corresponding to the given sandbox instantiation and which have an end time that denotes ongoing validity. In relation to record data from the timeline of the given sandbox instantiation, record data of the main instantiation which was valid up to the creation time of the given sandbox instantiation or up to the creation time of an earliest antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations may correspond to, for each component of the plurality of components, data items which correspond to the main instantiation, which have a start time before the respective creation time, and which have an end time that is after the respective creation time or which denotes ongoing validity. A data item may correspond to the main instantiation if the sandbox identifier is omitted. A data item may correspond to the main instantiation if the sandbox identifier matches the predetermined value of sandbox identifier as described hereinbefore. A given data item corresponding to the main instantiation may be superseded if any of the following conditions are met: ^ the corresponding component includes another data item having: o a data identifier identical to the given data item; o a sandbox identifier corresponding to the given instantiation; and o an end time denoting ongoing validity at the query time; ^ for each given antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations, the corresponding component includes another data item having: o a data identifier identical to the given data item; o a sandbox identifier corresponding to the given antecedent sandbox instantiation; o an end time valid up to the earlier of: ^ the creation time of the next antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and ^ the creation time of the given sandbox instantiation. In relation to record data from the timeline of the given sandbox instantiation, record data of that antecedent sandbox instantiation which was valid up to the earlier of the creation time of the subsequent antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations and the creation time of the given sandbox instantiation may correspond to, for each component of the plurality of components, data items which have a sandbox identifier corresponding to that antecedent sandbox instantiation, which have a start time before the respective creation time, and which have an end time that is after the respective creation time, or which denotes ongoing validity. A given data item of a given antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations may be superseded if the corresponding component includes another data item having: ^ a data identifier identical to the given data item; ^ a sandbox identifier corresponding to: o the given instantiation; or o any antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations which is a descendent of the given antecedent sandbox instantiation; ^ an end time valid up to the earlier of: o the creation time of the next antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and o the creation time of the given sandbox instantiation. In response to a write request in a given (or active) instantiation to store new data corresponding to a given data identifier to a given component of the plurality of components, the system may be configured to generate a new data item in the given component by storing the new data to the data payload of the new data item, setting the data identifier of the new data item equal to the given data identifier, setting the sandbox identifier to correspond to the given instantiation, and setting the start time equal to the time of the write request. The system may be configured to determine whether the given component includes a pre-existing data item which has a data identifier matching the given data identifier, has a sandbox identifier corresponding to the given instantiation and has an end time denoting ongoing validity. The system may be configured, in response to a positive determination of the pre-existing data item, to set the end time of the pre-existing data item equal to the time of the write request. The given instantiation may be the main instantiation. The given instantiation may be the a sandbox instantiation. In response to a deletion request in a given (or active) instantiation to delete a given data item from a given component of the plurality of components, the system may be configured, in a case where the given data item has a sandbox identifier corresponding to the given instantiation, to set the end time of the given data item to the time of the deletion request. The system may be configured, in a case where the given instantiation is a given sandbox instantiation, the given data item belongs to the timeline of the given sandbox instantiation, and the given data item has a sandbox identifier which corresponds to an antecedent instantiation, to generate a new data item in the given component by storing nothing in the data payload of the new data item, or copying the data payload of the given data item to the data payload of the new data item, setting the data identifier of the new data item to match the given data item, setting the sandbox identifier of the new data item to correspond to the given sandbox instantiation, setting the start time of the new data item equal to a time of the deletion request, and setting the end time of the new data item equal to the time of the deletion request. The given instantiation may be the main instantiation. The given instantiation may be the a sandbox instantiation. Merging the given (or source) sandbox instantiation into the target instantiation may include modifying record data of the target instantiation based on data items belonging to a merging set formed by subtracting an intersection of a first set and a second set from a union of the first set and the second set. The first set may consist of data items from the timeline of the given sandbox instantiation. In a case where the target instantiation is the main instantiation, the second set may consist of data items from the main instantiation which are valid up to a time of the merge. In a case where the target instantiation is a different sandbox instantiation from the given sandbox instantiation, the second set may consist of data items from the timeline of the different sandbox instantiation. Herein, if a first data item is described as “equal to” (or equivalently “identical to”) a second data item, this may mean that the first and second data items have identical values of the data identifier, the sandbox identifier and the start time. Set operations such as union, intersection and so forth carried out on sets of data items may use this preceding definition of equality as a condition for identity between a pair of data items. In this way, a data item may be included in the merging set unless that data item exists in both the first and second sets with identical values of the data identifier, the sandbox identifier and the start time (i.e. unless a data item exists in the first set which is equal to a data item in the second sets). Optionally, as an additional check, the data payloads may also be compared – whilst two data items having identical data identifier, sandbox identifier and start time should not ever have different data payloads, this check may identify if data has become corrupted or tampered with. The merging set may be collated after receiving a command to merge the given sandbox instantiation into the target instantiation and before generating any new data items. Alternatively, each data item of each component may be considered in turn, with membership of the merging set being determined in real-time (sometimes alternatively termed “on-the-fly”. Modifying record data of the target instantiation based on data items belonging to the merging set may include, for each given data item belonging to the intersection of the merging set and the first set, determining whether the component corresponding to the given data item comprises one or more pre-existing data items which have a data identifier matching the given data item and a sandbox identifier corresponding to the target instantiation or an antecedent instantiation of the target instantiation. In response to a negative determination, a new data item may be generated in the component corresponding to the given data item by copying the data payload and data identifier of the given data item to the new data item, setting the sandbox identifier of the new data item to correspond to the target instantiation, and setting the start time of the new data item equal to the time of the merge. Modifying record data of the target instantiation based on data items belonging to the merging set may include, for each given data item belonging to the intersection of the merging set and the first set determining whether the second set comprises a pre- existing data item which has a data identifier matching the given data item. In a case of a positive determination of one or more pre-existing data items, it may be determined whether the component corresponding to the given data item comprises a common antecedent data item. A common antecedent data item may have a data identifier matching the given data item, and may have a sandbox identifier corresponding to an instantiation which is an antecedent of the given sandbox instantiation and is the target instantiation or an antecedent of the target instantiation. In a case where the determination of the common antecedent data item is negative, the given data item may be flagged for conflict resolution. In a case where the determination of the common antecedent data item is positive and the data payload of the common antecedent data item is not the same as the data payload of the pre-existing data item, the given data item may be flagged for conflict resolution. In a case where the determination of the common antecedent data item is positive and the data payload of the common antecedent data item is the same as the data payload of the pre-existing data item, a new data item may be generated in the component corresponding to the given data item by copying the data payload and data identifier of the given data item to the new data item, setting the sandbox identifier of the new data item to correspond to the target instantiation, and setting the start time of the new data item equal to the time of the merge. In a case where the sandbox identifier of the pre-existing data item corresponds to the target instantiation, the end time of the pre-existing data item may be set equal to the time of the merge. Flagging a given data item for conflict resolution may include, or take the form of, adding the given data item to a list. The list may also include a corresponding data item which is in conflict with the given data item. Modifying record data of the target instantiation based on data items belonging to the merging set may include, for each given data item belonging to the intersection of the merging set and the first set, determining whether the component corresponding to the given data item includes one or more deleted data items having a sandbox identifier corresponding to the target instantiation or an antecedent instantiation of the target instantiation, and a data identifier which matches the given data item and does not match any data item belong to the second set. In response to a positive determination, the given data item may be flagged for conflict resolution. Modifying record data of the target instantiation based on data items belonging to the merging set may include, for each given data item belonging to the intersection of the merging set and the second set, determining whether the component corresponding to the given data item comprises one or more deleted data items having a data identifier which matches the given data item, which corresponds to the given sandbox instantiation or an antecedent instantiation of the given sandbox instantiation, and which does not match any data item belong to the first set. In response to a positive determination of one or more deleted data items, it may be determined whether the component corresponding to the given data item comprises a common antecedent data item. A comment antecedent data item may have a data identifier matching the given data item, and may have a sandbox identifier corresponding to an instantiation which is an antecedent of the given sandbox instantiation, and which is the target instantiation or an antecedent of the target instantiation. In a case where the determination of the common antecedent data item is negative, the given data item may be flagged for conflict resolution. In a case where the determination of the common antecedent data item is positive and the data payload of the common antecedent data item is not the same as the data payload of the given data item, the given data item may be flagged for conflict resolution. In a case where the determination of the common antecedent data item is positive and the data payload of the common antecedent data item is the same as the data payload of the given data item, the end time of the given data item may be set equal to the time of the merge. The system may be configured, in response to one or more data items being flagged for conflict resolution, for each given data item flagged for conflict resolution, to process the given data item according to pre-set rules, or to prompt the at least one client to decide how to process the given data item. The pre-set rules may be fixed. The pre-set rules may be user editable. For example, a user of the at least one client may be prompted to set conflict resolution rules, or select / adapt from a number of template conflict resolution rules, at the time of initiating the merge or at the time of generating the given sandbox. The user of the at least one client may be prompted during the merge. The user of the at least one client may be prompted upon requesting the merge but before starting the merge. In other words, the system may check the merging set and flag data items for conflict resolution, and require the user of the at least one client to provide input for all data items flagged for conflict resolution, before commencing the merge. Processing a conflict between a first data item from the given instantiation (merge source) and a second data item from the target instantiation may include one of: ^ replacing the second data item in the target instantiation by generating a new data item corresponding to the first data item and setting an end time of the second data item equal to a time of the merge; ^ setting the end time of the second data item to the time of the merge (i.e. deletion); or ^ generating a new data item based on both the first data item and the second data item. For each given data item belonging to an intersection of the merging set and the first set, the system may be configured to generate a new data item in the component corresponding to the given data item by copying the data payload and data identifier of the given data item, setting the sandbox identifier to correspond to the target instantiation, and setting the start time equal to the time of the merge. In a case where the second set comprises a pre-existing data item having a data identifier matching the given data item, an end time of the pre-existing data item may be set equal to the time of the merge. For each given data item belonging to an intersection of the merging set and the second, the system may be configured to determine whether the component corresponding to the given data item comprises one or more deleted data items having a sandbox identifier corresponding to the given sandbox instantiation or an antecedent instantiation of the given sandbox instantiation, and a data identifier which matches the given data item and which does not match any data item belong to the first set. In response to a positive determination, the end time of given data item may be set equal to the time of the merge. The data items belonging to each component of the plurality of components may be grouped into a main table including data items which belong to the main instantiation and which are valid at the present time, a history table including data items which belong to the main instantiation and which have an end time before the present time, and a shadow table including the data items which belong to sandbox instantiations. The data items in the shadow table of a given component may be valid in some sandbox instantiations, whilst being no longer valid (deleted or superseded) in other sandbox instantiations, and / or irrelevant to still other sandbox instantiations. The system may be configured to process a read query in a given sandbox instantiation by, for each given component of the plurality of components, determining a sandbox set by filtering a set of all data items matching the read query in the shadow table of the given component to select, for each unique data identifier, the most recent valid data item on the timeline of the given sandbox instantiation. The system may be configured to process a read query in a given sandbox instantiation by, for each given component of the plurality of components, determining a main set by filtering a union of data items in the main table matching the read query and belonging to the timeline of the given sandbox instantiation, and data items in the history table matching the read query and belonging to the timeline of the given sandbox instantiation. The filtering may remove any data items of the main set having a data identifier which matches a data item belonging to the sandbox set. The system may be configured to process a read query in a given sandbox instantiation by, for each given component of the plurality of components, generating a read output set as the union of the main set and the sandbox set. In this way, the division of data items into main, history and shadow tables may reduce the complexity of determining and returning data items from the timeline of the given sandbox instantiation which match the read query. Reducing the number of operations necessary to accomplish the read query reduces computational cost and therefore also power expended by the system maintaining the computing environment. Each data item may also include a deleted flag. In a case where a given data item is deleted in a given instantiation, a new data item may be generated in the given instantiation by storing nothing in the data payload of the new data item, or copying the data payload of the given data item to the data payload of the new data item, by setting the data identifier of the new data item to match the given data item, by setting the sandbox identifier of the new data item to correspond to the given instantiation, by setting the start time of the new data item equal to a time of the deletion request, by setting the end time of the new data item to indicate ongoing validity, and by setting the deleted flag of the new data item to true. In the case that the given data item has a sandbox identifier corresponding to the given instantiation, the end time of the given data item may be set equal to the time of the deletion request. The given instantiation may be the main instantiation or a sandbox instantiation. In this way, identification of deleted data items in the given sandbox instantiation may be simplified, since comparison of the end time with a present time may be avoided by simply checking for deleted (or “tombstone”) flags instead. A read query may include a filter based on the deleted flag. For example, a default ready query may include a filter to exclude data items having a deleted flag set to false. In this way, deleted items may still belong to the timeline of a given sandbox instantiation, whilst being generally excluded from visibility by filtering out data items having a deleted flag set to true. A user of the at least one client may modify the read query to include deleted data items from the respective timeline by removing the filter on the deleted flag. Alternatively, a user of the at least one client may modify the read query to return only deleted data items having a deleted flag set to true. In a case where data items comprise the deleted flag, any of the features described herein which relate to conflict detection and which including a condition to detect a deleted item based on the end time of a given data item, may alternatively check the deleted flag to determine whether the given data item has been deleted. Each data item may also include a validity flag having a binary (true or false) value. The system may be configured to maintain the validity flags of each given data item such that, in a case where the given data item is the most recent data item corresponding to the combination of data identifier and sandbox identifier matching the given data item, the validity flag of the given item is set to true. The validity flag may be updated in parallel with any or all of the operations or processes described herein in relation to reading, generating, deleting (set validity flag equal to false or null) or otherwise processing data items of one or more components. By maintaining the validity flag, determining the data items belonging to the timeline of a given sandbox instantiation may be simplified. The at least one client may be permitted, within a given sandbox instantiation to which the at least one client has access, to install or update all or part of a software application which is executable within the given sandbox instantiation of the computing environment. The installation or updating of a software application executable within the given sandbox instantiation of the computing environment may include, or take the form of, replacing any or all files etc corresponding to that application within component storing that application. For example, a data item may have data payload corresponding to executable computer code for the application, and the data identifier may be a file location (in a file system being used within the computing environment). Other data items associated with an application may include libraries, configuration files, data repositories used by the application, and so forth. All data items corresponding to an application may belong to a single component. Alternatively, data items corresponding to an application may be distributed across two or more components. Data items may be common to two or more applications, for example, a shared library or other resource useable by two or more applications. The system may be configured such that merging the given sandbox instantiation with the target instantiation will cause the installed or updated software application to be executable within the target instantiation of the computing environment. The at least one client may be permitted to generate a sandbox instantiation of the computing environment within a main instantiation of the computing environment or within a previously generated sandbox instantiation of the computing environment at the present time, or at a time in the past. A read query may be processed at the present time, or at a time in the past. A first sandbox instantiation may be merged with the state of a second sandbox at a time in the past by generating a third sandbox instantiation within the second sandbox instantiation and having a creation time corresponding to the desired time in the past, then merging the first and third sandbox instantiations. According to a second aspect of the invention, there is provided a method executed by at least one programmable processor, the method including maintaining a computing environment comprising a plurality of components, each component storing record data. The method also includes permitting at least one client to access the computing environment. The method also includes permitting the at least one client to generate a sandbox instantiation of the computing environment within a main instantiation of the computing environment or within a previously generated sandbox instantiation of the computing environment to which the at least one client has access. Each sandbox instantiation has a creation time. A read query in a given sandbox instantiation returns record data from a timeline of the given sandbox instantiation which matches the read query. The record data from the timeline of the given sandbox instantiation consists of: ^ record data of the given sandbox instantiation which is valid up to a time of the read query; and ^ in a case where the given sandbox instantiation is a direct descendant of the main instantiation, record data of the main instantiation which was valid up to the creation time of the given sandbox instantiation and which is not superseded by record data of the given sandbox instantiation; ^ in a case where the given sandbox instantiation is descendant from the main instantiation via a sequence of one or more antecedent sandbox instantiations: o record data of the main instantiation which was valid up to the creation time of an earliest antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations and which is not superseded by record data of the given sandbox instantiation or record data of a sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and o for each of the sequence of one or more antecedent sandbox instantiations, record data of that antecedent sandbox instantiation which is not superseded by record data of the given sandbox instantiation or record data of a subsequent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations and which was valid up to the earlier of: ^ the creation time of the next antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and ^ the creation time of the given sandbox instantiation. The method of the second aspect may include any features described in relation to the system of the first aspect. Definitions applicable to the system of the first aspect (or features thereof) may be equally applicable to the method of the second aspect (or corresponding features thereof). According to a third aspect of the invention, there is provided a system including at least one programmable processor and at least one machine-readable medium storing instructions that, when executed by the at least one programmable processor, cause the at least one programmable processor to permit at least one client to access a computing environment comprising a plurality of components. Each component stores one or more data items. Each data item includes data payload, a data identifier, a sandbox identifier, a start time, and an end time. The at least one programmable processor is also caused to permit the at least one client to generate a sandbox instantiation of the computing environment within a main instantiation of the computing environment or within a previously generated sandbox instantiation of the computing environment to which the at least one client has access. Each sandbox instantiation has a creation time. Each given data item is valid within an instantiation corresponding to its sandbox identifier at, or after, the respective start time and before the respective end time. Ongoing validity of a data item is denoted by omitting the end time or by setting the end time to a predetermined ongoing validity value. A read query in a given sandbox instantiation returns data items from a timeline of the given sandbox instantiation which matches the read query. The data items from the timeline of the given sandbox instantiation consist of: ^ data items corresponding to the given sandbox instantiation and having end times which are valid at a time of the read query; ^ in a case where the given sandbox instantiation is a direct descendant of the main instantiation, data items corresponding to the main instantiation, which have an end time valid at the creation time of the given sandbox instantiation, and which are not superseded by data items of the given sandbox instantiation having the same data identifier; ^ in a case where the given sandbox instantiation is descendant from the main instantiation via a sequence of one or more antecedent sandbox instantiations; o data items corresponding to the main instantiation which have an end time valid at the creation time of an earliest antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations, and which is not superseded by data items having the same data identifier and corresponding to the given sandbox instantiation or the sequence of one or more antecedent sandbox instantiations and having the same data identifier; o for each of the sequence of one or more antecedent sandbox instantiations, data items corresponding to that antecedent sandbox instantiation which are not superseded by data items having the same data identifier and corresponding to the given sandbox instantiation or a subsequent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations, and which was valid up to the earlier of: ^ the creation time of the next antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and ^ the creation time of the given sandbox instantiation.

[0002] Brief Description of the Drawings Certain embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which: Figure 1 schematically illustrates a conventional sandboxing system; Figure 2 schematically illustrates an improved computing environment including a main instantiation and supporting one or more sandbox instantiations; Figure 3 schematically illustrates hardware components suitable for implementing the improved computing environment; Figure 4 schematically illustrates the organisation of data within the improved computing environment; Figure 5 schematically illustrates examples of sandbox instantiations; Figure 6 is a process flow diagram for a method of processing a read query within a sandbox instantiation; Figure 7 is a process flow diagram of an example method for determining whether record data belongs to the timeline of a sandbox instantiation; Figure 8 is a process flow diagram of an example method for determining whether record data belonging to the timeline of a sandbox instantiation is superseded by more recent record data; Figure 9 is a process flow diagram for a method of merging a source sandbox instantiation with a target instantiation; Figure 10 is a process flow diagram for an example method of detecting conflicts between record data during a merge process; Figure 11 is a process flow diagram illustrating further details of an optional process shown in Figure 10; Figure 12 schematically illustrates one example of a format for record data, in the form of data items; Figure 13 schematically illustrates a sandbox table used to keep track of relationships between sandbox instantiations; Figure 14 is a worked example using the format shown in Figure 12; Figure 15 is a process flow diagram for an example method of processing a read query within a sandbox instantiation when record data take the form of data items; Figure 16 is a process flow diagram for an example method of processing a write or modification request within a sandbox instantiation when record data take the form of data items; Figure 17 is a process flow diagram for an example method of processing a deletion request within a sandbox instantiation when record data take the form of data items; Figures 18A and 18B schematically illustrate modifying the structure of a data item; Figure 19 is a process flow diagram for a method of merging a source sandbox instantiation with a target instantiation when record data takes the form of data items; Figure 20 schematically illustrates sets of data items used during the merging process of Figure 19; Figure 21 is a process flow diagram for an example method of detecting conflicts between data items during a merge process; Figure 22 is a process flow diagram illustrating further details of a step shown in Figure 21; Figure 23 is a process flow diagram illustrating further details of a step shown in Figure 21; Figure 24 schematically illustrates a further example of a format for record data, in the form of data items stored in three separate tables; Figure 25 shows the data from the worked example of Figure 14, converted to the format shown in Figure 24; Figure 26 is a process flow diagram for an example method of processing a read query within a sandbox instantiation when record data take the form of data items stored in three separate tables; Figure 27A schematically illustrates a conventional process for updating or upgrading a software application; and Figure 27B schematically illustrates a process for updating or upgrading a software application using sandbox instantiations. Detailed Description of Certain Embodiments In the following description, like elements are denoted by like reference numerals. A problem for users of existing sandbox systems is an inability to make safe, timely changes to their main computing environment to support constantly changing needs of their organization. Whilst existing sandbox systems provides a secure testing sandbox environment to test an individual system change without impacting operation, production and so forth (depending on the type of organisation), they do not adequately fulfil user’s needs for controlled change management of workflows which often include complex integrations and the continuous data creation from multiple users across an organization (potentially including sensors and automated processes in addition to human users). Small changes such as adding a field to an existing database, or creating an approval workflow, can take weeks, whereas implementing tested changes to the main computing environment can take six months to a year. These change timelines tend to increase as an organisation scales due to increased integration complexity and volume of data creation. The time consuming nature of the change process arises because user testing conducted in a conventional sandbox environment is typically based on a snapshot of the organisational data that quickly goes stale during the period of a project to develop a new module / function etc. Additionally, conventional sandbox systems typically support only one, or a small number, of sandbox environments which must consequently be shared by all users across the entire organization. Adding further, conventional sandbox environments are laborious and cost intensive – both financially and in terms of computing resources, since a complete copy of all data in the main computing environment must be obtained and then maintained to operate a conventional sandbox environment. Data volumes can rapidly exceed petabytes, even for relatively small organisations, rendering significant parallelisation of multiple conventional sandbox environments impractical. Data refreshes of a conventional sandbox environment must often be coordinated across competing projects – which can lead to sacrificing testing quality or creation of additional manual work. Finally, changes extensively tested in a conventional sandbox computing environment must then be re-built and retested in the main computing environment, introducing additional risk. For example, using conventional sandbox computing environments, it would not be possible to determine conflicts with changes to the main computing environment before implementation without, for example, suspending the main computing environment long enough to refresh the data of the sandbox computing environment, then repeating testing. By the time this is completed, the representation of the main computing environment may well be obsolete again. Conventional sandboxing approach Referring to Figure 1, a conventional sandboxing system 1 is shown. The conventional sandboxing system 1 includes a main computing environment 2. At a time t0, a complete copy of the main computing environment 2 is obtained, and then used to build a completely separate, conventional sandbox computing environment 3. As will be apparent, obtaining the copy of the main computing environment 2 data can be a time consuming operation, scaling poorly with the size of an organisation. Obtaining a data copy to setup a conventional sandbox environment 3 can take anywhere between seconds for smaller data volumes, up to hours for larger data volumes. When the main computing environment of an organisation is spread across multiple different sites (potentially spanning multiple time zones), the time involved may be compounded. Consequently, setting up a conventional sandbox computing environment 3 may take hours or days, during which time users must usually be excluded from making modifications or accessing the main computing environment 2. The impracticalities of scheduling such downtime of their main computing environment 2 limits the utility and application of conventional sandbox computing environments 3 by many organisations. A further potential issue with conventional sandbox computing environments 3 arises when patches or software updates are released – these must be applied separately to the main computing environment 2 and the sandbox computing environment 3. There are also often difficulties in merging a conventional sandbox computing environment 3 with the main computing system, leading to accumulation of changes over time that need to be migrated between the environments 2, 3, often manually. System copies for generating a sandbox computing environment 3 can often only be created by system administrators, causing significant delays for other users who have to request and wait for them. Additionally, ensuring that the copy in the conventional sandbox computing environment 3 behaves exactly like the original main computing environment 2, for example in terms of runtime and load behaviour is a challenging task. Due to the previously described limitations, once setup the conventional sandbox computing environment 3 is usually shared by multiple projects. In the example shown in Figure 1, the conventional sandbox computing environment 3 is used for the development of four new features 4a, 4b, 4c, 4d. Features may include new data, new functionalities (implemented by new executable computer code), modelling or calculations, and so forth. Each of the features is worked on separately by a different team, showing the conventional sandbox computing environment 3. Even though the first feature 4a is completed relatively quickly, because the other project teams are still making changes to the other new features 4b, 4c, 4d, quality assurance evaluation 5 (including but not limited to testing) needs to be delayed until all the projects 4a, 4b, 4c, 4d are completed. This can increase the complexity of quality assurance evaluation 5. Once all the features 4a, 4b, 4c, 4d have been completed and passed quality assurance evaluation 5, at time t1the new features 4a, 4b, 4c, 4d must then be transferred across to the main computing environment 2. This may often require significant manual input and / or rebuilding of the features 4a, 4b, 4c, 4d within the main computing environment 2. The overall lapse in time between time t0and t1may be months, meaning that even though quality assurance evaluation 5 was performed based on the state of the main computing environment 2 at time t0, there may be inconsistencies or conflicts which have developed by the time the features 4a, 4b, 4c, 4d are implemented in the main computing environment 2 at time t1. Such risks can be difficult to mitigate in a conventional sandboxing system 1. The investment of time and computing to setup a conventional sandbox computing environment 3 may also discourage use for investigating bugs or other issues experienced within the main computing environment 2 and developing patches or “hot fixes” to resolve them. New sandboxing approach Referring also to Figure 2, an improved computing environment 6 in accordance with the present specification is shown. Compared to the conventional sandbox system 1, the computing environment 6 can maintain a main instantiation 7 in parallel with multiple sandbox instantiations 8, without the necessity to copy any data from the main instantiation 7 of the computing environment 6. Moreover, in the computing environment 6, sandbox instantiations 8 are not limited to being created from the main instantiation 7, and may be generated within other, previously generated sandbox instantiations 8. References herein to “main” should be understood as referring to the main instantiation 7 of the computing environment 6, and similarly references to a “sandbox” should be understood as referring to a sandbox instantiation 8 of the computing environment 6. The details of how this is achieved are the subject of the rest of this specification, but at a high level, each sandbox instantiation 8 only stores modifications made relative to the main instantiation 7 and zero or more antecedent sandbox instantiations 8 (explained further in relation to Figure 5). At the same time, the computing environment 6 implements rules which ensure that each sandbox instantiation 8 can only “see” (or alternatively have visibility of) data belonging to itself and its antecedent instantiations (main 7 and any number of sandboxes 8). The data that a given sandbox instantiation 8 can see, referred to herein as that sandbox instantiations “timeline”, is explained in greater depth in relation to at least Figures 5 to 8 and 15. This concept also applies to the modification of data within a sandbox instantiation 8 – which will only change the data seen by that sandbox instantiation 8 (and any descendant sandbox instantiations 8 generated from it after the data is modified). This is accomplished used copy-on-write processes, and is explained further in relation to Figures 4 through 11 and 16 through 23. In this way, an object may exist simultaneously in multiple versions, each visible to different sets of instantiations 7, 8. This combination of data storage structure and rules limiting instantiations 7, 8 to access data from their corresponding timelines, permits both access to up-to-date main instantiation data 7 (for example up to the creation time of a sandbox instantiation 8) and massive parallelisation of the sandbox instantiations 8. When a new sandbox instantiation is generated, no data needs to be copied, allowing setup within seconds or less even in the largest scale organisations. Moreover, the performance characteristics of the sandbox instantiation 8 may not be perceptibly depreciated (from a user perspective) when compared to the main instantiation 7. See for example the optimised three-table schema described in relation to Figures 24 to 26. Additionally, the additional computing resources and storage associated with new sandbox instantiations 8 are limited to only the modified data therein. Furthermore, because each sandbox instantiation 8 can see the data of the main instantiation 7 in addition to its own data (and data of any antecedent sandbox instantiations on its timeline), a sandbox instantiation 8 can work with the state of data from the main instantiation 7 right up to the point when the timeline of that sandbox instantiation branched from the main instantiation 7, without risk of affecting the main instantiation 7. This reduces (and using re-basing described hereinafter potentially eliminates) the problem of “stale” data, and allows for improved checking for conflicts with data of the main instantiation (see also conflict checking methods explained in relation to Figures 9 to 11 and 19 to 23). Even though the main instantiation 7 and any number of sandbox instantiations 8 may be accessing the same data (for example when it has not been modified in the timeline of a sandbox instantiation), the computing environment 6 remains secure due to the previously mentioned copy-on-write processes (and explained in greater detail hereinafter). For example, malicious code executed in a sandbox instantiation 8 might write new malicious and / or corrupted data to that sandbox instantiation 8, and this may propagate to descendent sandbox instantiations 8. However, the main instantiation 7, any antecedent sandbox instantiations 8, and any unrelated sandbox instantiations 8, all remain unchanged and secure unless the affected sandbox instantiation is merged with them. This security is built in via the basic rules of operation configured into the computing environment 6. Herein, the numeral “8” is used to refer to sandbox instantiations in general, and may have further identifiers appended in specific figures and / or descriptions to denote particular illustrated examples, for example 8a, 81and so forth. Returning to the specific example shown in Figure 2, a comparison to the use of the conventional sandbox system 1 to develop new features 4a, 4b, 4c, 4d is shown. At time t0(the “creation time”) a first sandbox instantiation 8a is generated within the main instantiation 7. The first feature 4a is developed in the first sandbox instantiation 8a, with visibility to data from the main instantiation 7 up to time t0. Only new data added, or modified, within the first sandbox instantiation 8a needs to be stored, and data modified and / or added within the first sandbox instantiation 8a is not visible in the main instantiation 7 until the data from the first sandbox instantiation 8a is merged into the main instantiation 7 at time t3to import the first feature 4a into the main instantiation 7. Whilst the merging may simply overwrite data in one instantiation 7, 8 with data from the source sandbox instantiation 8, preferably the merging process incorporated detection and resolution of conflicts. Further details of merging data from different instantiations (and conflict checking and resolution) are provided hereinafter with reference to Figures 9 to 11 and 19 to 23. Since the first sandbox instantiation 1 is not required for development of other features 4b, 4c, 4d, once the development of the first feature 4a is complete, corresponding quality assurance evaluation 5a may be conducted without delay. This may help to reduce the volume and complexity of the quality assurance evaluation 5a. At time t1, a second sandbox instantiation 8b is generated within the main instantiation 7 for development of the second feature 4b, and has visibility to data of the main instantiation 7 up to time t1. The second sandbox instantiation 8b exists in parallel with the first sandbox instantiation 8a, and data from each sandbox instantiation 8a, 8b is not visible to the. Once the second feature 4b is finished, quality assurance evaluation 5b may be begun immediately, and once passed the data from the second sandbox instantiation 8b is merged with the main instantiation 7 at time t5to import the second feature 4b. Similarly, a third sandbox instantiation 8c is used to develop the third feature 4c between times t2 and t7, and a fourth sandbox instantiation 8d is used to develop the fourth feature 4d between times t4and t6. The first feature 4a is visible within the fourth sandbox instantiation 8d, because its creation time tcreate= t4is after the first sandbox instantiation 8a is merged with the main instantiation 7 at time t3. Although not shown in Figure 2, sandbox instantiations 8 are not limited to being generated within the main instantiation 7, and in general a sandbox instantiation 8 may be generated within the main instantiation 7 or any other sandbox instantiation 8, and may be merged with the main instantiation or any other sandbox instantiation 8. Merging of sandbox instantiations 8 is also not limited to only antecedent sandbox instantiations 8 or the main instantiation 7. Another feature of the computer environment 6 is that sandbox instantiations 8 may be quickly and easily “re-based” to include the most recent data from the main instantiation 7 (or any other sandbox instantiation). For example, after the first feature 4a is completed but before conducting quality assurance evaluation 5a, a fifth sandbox instantiation (not shown in Figure 2) can be generated within the main instantiation 7 and having visibility of the main instantiation 7 data up to the present time (i.e. after t0), and the first sandbox instantiation 8a is then merged with the fifth sandbox instantiation. The quality assurance evaluation 5a can then be conducted using the most up-to-date data of the main instantiation 7, reducing the possibility of a conflict or incompatibility going undetected by the quality assurance evaluation 5a. The processing of rebasing sandbox instantiations 8 is described in further detail hereinafter in connection with the merging processes (see Figures 9 to 11 and 19 to 23 and accompanying description. Because only the relevant modified data needs to be copied, the re-basing of a sandbox instantiation 8 can remain rapid and does not require significant computational resources. Examples of uses for sandbox instantiation 8 within the computing environment 6 may include, without being limited to: ^ Loading external data: for example when significant data manipulation is needed while loading external data into the system. ^ Process changes: When there is a need to modify existing processes within an organisation, or to introduce new ones. ^ Systems integrations: When two of more previously separate computer systems 9 need to be integrated into a single computing environment 6. ^ Simulations: Conducting simulations to evaluate different scenarios or to analyse the impact of changes. ^ Integrations: Connecting with external or internally developed systems for seamless data exchange. ^ Upgrade Testing: Testing the impact of upgrading software applications within the computing environment 6 to newer versions or patches (see also Figure 27B). ^ Data Analysis: Performing data analysis and reporting activities. ^ Investigating bugs / issues; ^ Preparation, testing and deployment of patches or “hot fixes”; ^ Retrospective / historical analysis – data in the computing environment 6 is not deleted, and instead is superseded by later data. The processes for read queries described hereinafter (see for example Figures 6 to 8) may be evaluated at the present time – or at any given point in the past. This greatly simplifies processes such as retrospective calculations, technical or other audits, and understanding the causes of bugs (for example by reproducing conditions corresponding to a reported bug). The processes described herein for generating new sandbox instantiations 8 are also not limited to being carried out at the present time – a new sandbox instantiation 8 may be generated using a create time (tcreate) which is in the past. In these ways, and as further discussed hereinafter, the computing environment 6 provides a distinctive new type of environment, which may enable system simulations, simplified system landscapes, easier upgrades, new workflow processes, and so forth. The computing environment 6 allows users to create a fully isolated environment (excepting global data / components described hereinafter), the sandbox instantiation 8, within that computing environment 6. When a user enters a sandbox instantiation 8 (whether newly generated, or entering an existing sandbox instantiation), all their actions and changes are kept completely private and separate from the main instantiation 7 and any concurrently active sandbox instantiations 8. Only a descendent (or “child”) sandbox instantiation 8 generated within an active sandbox instantiation 8 (see for example 82in Figure 5) will see the changes made, and then only those changes made up to (but not including) the creation time tcreateof that descendent sandbox instantiation 8. The user sees the data from antecedent instantiations 7, 8 exactly as it was when the active sandbox instantiation was created. Any subsequent changes made are only visible within the active sandbox instantiation, and the system load they generate is minimal or negligible in terms of the overall system performance (since wholesale duplication of large quantities of data is not required. The isolation provided by sandbox instantiations 8 encompasses, without being limited to, data, coding, metadata, process definitions, user interface(s), and runtime. Essentially, each sandbox instantiation provides the user(s) with their own application server runtime. To aid understanding and brevity of the following, the following terminology shall be used herein. In a case that a second sandbox instantiation 8 is generated within a first sandbox instantiation 8 (see for example 82in Figure 5), the second sandbox instantiation 8 shall herein be described as being a direct descendant of the first sandbox instantiation 8. Additionally (and equivalently) the first sandbox instantiation 8 can be described as being a direct antecedent of the second sandbox instantiation 8. Similarly, the concepts of descendent and antecedent sandbox instantiations 8 may be applied to span multiple generations. For example, if a third sandbox instantiation 8 is generated within the aforementioned second sandbox instantiation 8, then the third sandbox instantiation 8 shall herein be described as a descendent of the first sandbox instantiation 8 as well as being described as a direct descendent of the second sandbox instantiation 8 (see for example 88, 810and 811in Figure 5). Similarly, the first sandbox instantiation 8 can be described as an antecedent of the third sandbox instantiation 8, whilst the second sandbox instantiation 8 can be described as a direct antecedent of the third sandbox instantiation 8. Extending the example, in a case where a fourth sandbox instantiation 8 is generated within the third sandbox instantiation 8, the fourth sandbox instantiation 8 shall be described as being descended from the main instantiation 7 via a sequence of one or more antecedent sandbox instantiations 8 – the sequence including, in order, the second sandbox instantiation 8 followed by the third sandbox instantiation 8. In a case where a fifth sandbox instantiation 8 and a sixth sandbox instantiation 8 are not related as descendant / antecedent (see for example 89and 811in Figure 5), we herein describe a sandbox instantiation which is an antecedent of both the fifth and sixth sandbox instantiations 8 as being a common antecedent for the fifth and sixth sandbox instantiations (see for example 88in Figure 5). Computing environment Referring also to Figure 3, an example of hardware components implementing the computing environment 6 is shown. One approach to implementing the computing environment 6 is using one or more computer systems 9 coupled via one or more networks 12 to one or more data repositories 10 and one or more network clients 11a. Each computer system 9 includes at least one at least one programmable processor 13 (a digital electronic processor), volatile memory 14 and local, non-volatile storage 15 (for example at least one machine- readable medium), coupled together by a bus (not shown). The local storage 14 stores instructions that, when executed by the processor 13, carry out the processes and functionalities of the computing environment 6 described in the present specification. Any (or all) of the computer systems 9 may optionally support a local client 11b. The one or more network(s) 12 may include the internet (world wide web), local intranets and so forth, and may be implemented using wired connections, wireless connections, or more generally a mixture of wired and wireless connections. Each data repository 10 may store any type of data / information that may be stored on computer readable media and which may it is desired to use, access, execute or otherwise manipulate by or within the computing environment 6. For example, data repositories 10 may store any combination of: ^ Database table(s) 16; ^ Executable computer code 17 (for example for applications that may be run inside the computing environment); ^ Rules 18; ^ Configurations (not shown in Figure 3, for example preferences and / or permissions corresponding to different users / clients 11a, 11b); ^ Source code (not shown in Figure 3); ^ Metadata; ^ Embeddings used by a machine learning (ML) model (not shown in Figure 3), such as a large language models (LLM); and ^ Graphical design elements including templates and images (not shown in Figure 3). The preceding list is not exhaustive or intended to limit the scope of what may be stored and / or manipulated by or within a particular computing environment 6. The contents of data repositories 10 may vary amongst different particular computing environments 6 implemented in accordance with the present specification. Examples of rules 18 which may be applied in some implementations may include uniqueness (for example, a MAC address field), that all of one or more required entries are present (for example, an e-mail address for a customer), validations (for example, an e-mail address has a valid format), and so forth. The local storage 15 of any (or all) of the computer systems 9 may additionally store any type of data stored by a data repository 10. Indeed, at a minimum, the computing environment may be implemented using a single computer system 9, using a local client 11b and using and / or processing data stored by local storage 15. The methods of the present specification are, however, expected to be most advantageous when applied to a computing environment 6 implemented between a large number of computer systems 9, a larger number of data repositories 10, and a large number of network 11a and / or local 11b clients. Referring also to Figure 4, a high level overview is shown of how data is organised within the computing environment 6. Clients 11a, 11b are permitted (subject to typical access control measures) to access the computing environment 6, which includes a number N (positive integer > 0) of components, each denoted as COMP. Each component COMP exists in Mn(positive integer > 0) independent versions. Herein COMP(n,mn) denotes the mnthof Mn versions of the nthof N components, index n runs from 1 to N and index mnruns from 1 to Mn. The number N of components COMP and the numbers Mnof versions of each are not limited except by available storage capacity. Each value of Mn, being the maximum number of versions for nthcomponent COMP is independent of the values of Mn. In other words, although Figure 4 illustrates the components and versions COMP(n,mn) in a rectangular array, in reality the number Mnof versions of each of the N components COMP will vary. In practice, it is expected that most components COMP will only require one, or a relatively small number of versions, although if necessary there is no hard limit on the numbers Mnof versions. New component versions COMP(n,Mn+1) are only generated when the underlying structure changes. For example if the nthcomponent COMP(n,1) corresponds to a database table, if a new field is added then a new version COMP(n,2) may be generated. The whether a new version COMP(n,Mn+1) is required depends, in this example, on whether the new field is optional or required, with the latter requiring the new version COMP(n,Mn+1). Modifying the structure of a component COMP(n,mn), or data stored therein, is also referred to herein as a “migration”. Migrations may be “compatible” (not necessarily requiring a new version COMP(n,Mn+1)) or “incompatible” (requiring a new version COMP(n,Mn+1)), as described in greater detail hereinafter (see for example Figures 18A and 18B). If the new version COMP(n,2) is generated within a sandbox instantiation 8, then the new version COMP(n,2) will only be visible on the timeline of that sandbox instantiation 8 (or sandbox instantiations 8 subsequently generated within it). Further details of component versioning are explained hereinafter (see for example Figures 18A, 18B and corresponding description). Each component COMP(n,mn) stores one or more items of record data, each corresponding to an object such as, for example, a data table having a number of fields and any number of rows, script files, compiled code forming a library, a dynamic link library, a configuration file, source code, executable computer code, embeddings used by a machine learning (ML) large language model (LLM), graphical design elements including templates and images, or any other type of object capable of definition in a computing environment 6 and storable to a computer readable medium. Data items data(kn,m) (Figure) 12 are one, non-limiting example of items of record data. If a component COMP(n,mn) stores a number Kn,mof items of record data, then let the kn,mthitem of record data be denoted as record(kn,m). It should be noted that the number Kn,mof items of record data record(kn,m) stored in a particular component COMP(n,mn) is not fixed, and simply denotes the number of items of record data record(kn,m) stored by component COMP(n,mn) at the relevant time. The components COMP(n,mn) are in common, which is to say that the computing environment 6 only includes a single set of the components COMP(n,mn). The separation between instantiations 7, 8 is provided by the processes using by the computing environment 6 to determine and enforce which versions of components COMP(n,mn) and within those which specific items of record data record(kn,m) are visible on the timelines of each sandbox instantiation 8 and the main instantiation 7. In particular, the computing environment 6 tracks, for each item of record data record(kn,m), the instantiation 7, 8 it belongs to and the time periods for which it is valid. This may be accomplished using any suitable approach, for example using metadata tags, or using a specific data structure including this information, such as the data items data(kn,m) described hereinafter with reference to Figures 12 to 18B. In some implementations, aspects of implementing the computing environment 6 itself such as, for example, source code, metadata, configuration files, UI elements, model data, or any user modifiable artefact in the computing environment, may be stored as components COMP(n,mn). Preferably, a small amount of platform code (sometimes termed the “kernel) is stored outside of the structure of components COMP(n,mn) to provide low level runtime services. Sandbox instantiations Referring also to Figure 5, examples of the usage of sandbox instantiations 8 and are schematically illustrated, along with the respective timelines of first to eleventh example sandbox instantiations 81, …, 811. The computing environment 6 is configured to permit a client 11a, 11b to generate a sandbox instantiation 8 of the computing environment 6 within the main instantiation 7 of the computing environment or within any previously generated (i.e. already existing) sandbox instantiation 8 of the computing environment 6 to which that client 11a, 11b has access permissions. Access permissions to a given sandbox instantiation 8 may be set depending on requirements, but may for example include different levels of access such as: ^ Read only; ^ Read and write; ^ Read, write and generate descendent sandbox instantiations. Each sandbox instantiation also has a creation time tcreate. Referring to the examples shown in Figure 5, a first sandbox instantiation 81is generated within the main instantiation 7 as time t1, a second sandbox instantiation 82is generated within the first sandbox instantiation 81at time tcreate=t2, a third sandbox instantiation 83is generated within the main instantiation at time tcreate= t3, and so forth. Before describing the use cases represented by the examples of first 81to eleventh 811sandbox instantiations shown in Figure 5 in further detail, it shall be useful to explain, with reference also to Figures 6 to 8, the processes used within the computing environment 6 to provide separation virtualisation of each sandbox instantiation. The labels “SBID” relate to a subsequent example of one specific implementation of the computing environment 6, and shall be explained hereinafter with reference also to Figures 12 and 13. Referring in particular to Figure 6, a first key process is control of which record data record(kn,m) is visible from within an originating (or “given”) sandbox instantiation 8. This corresponds to the record data record(kn,m) that would be returned in response to a read query made by a user (or a process) from within the originating sandbox instantiation 8. The process is initialised for the first item of record data record(1) (step S3) stored in the first version (step S2) of the first component COMP(1,1) (step S1). The currently considered item of record data record(kn,m) is screened to determine whether it matches the received read query (step S4). If the item of record data record(kn,m) does not match the read query (step S4|No), then the process proceeds to check whether there are further items of record data record(kn,m) to consider within the nthand mnthcomponent COMP(n,mn) (step S7), and if not (step S7|No), the index kn,mis incremented (step S8) and the next item of record data record(kn,m+1) is checked (step S4). Typically an item of record data record(kn,m) matches the read query if that item of record data record(kn,m) matches one or more filters or other parameters defined in the read query. The one or more filters or other parameters may be user specified via the client 11a, 11b accessing the originating sandbox instantiation 8. Alternatively, filters or other parameters may be predetermined, or may include a mixture of predetermined and user specified filters or other parameters. Predetermined filters or other parameters may vary in dependence on a context of the read query. Non-exhaustive examples of filters or other parameters which may be included in a read query include a range of modification date and / or time, one or more keywords, a range of file sizes, one or more author(s) (for example tagged in metadata), a filter to remove record data that has been indicated or flagged as deleted, a filter on permissions of the requesting user (they will only see data they are authorised for), and so forth. If the currently considered item of record data record(kn,m) matches the read query (step S4|Yes), it is checked whether that item of record data record(kn,m) is from the timeline of the originating sandbox instantiation 8 (step S5). The determination of whether an item of record data record(kn,m) belongs to the originating sandbox instantiation 8 is explained in detail hereinafter with particular reference to Figures 7 and 8. If the item of record data record(kn,m) does not belong to the timeline of the originating sandbox instantiation 8 (step S5|No), then it is checked whether there are any further items of record data record(kn,m) to consider (step S7). However, if the item of record data record(kn,m) belongs to the timeline of the originating sandbox instantiation 8 (step S5|Yes), then it is added to a results list (step S6) before checking whether there are further items of record data record(kn,m) to consider (step S7). Once all items of record data record(kn,m) for the current component COMP(n,mn) have been checked (step S7|Yes), the process is repeated for each version (steps S9 and S10) of each component COMP(n,mn) (steps S11 and S12) in order to find all the items of record data record(kn,m) from the timeline of the originating sandbox instantiation 8 which match the read query. In some examples, the order of steps S4 and S5 may be reversed, though often it may be simpler to check matching to the read query leading to improved efficiency when this is used as the first test for inclusion in the results list. Other optimisations may also be implemented. For example, the creation time tcreateof the query originating sandbox instantiation 8 may be cross-referenced to a list of component COMP(n,mn) versions. Only the version mnwhich is applicable to the query originating sandbox instantiation 8 needs to be searched. Optionally, the results list may be combined (union) with any global record data (described hereinafter) and / or other data which also match the read query (step S13), before being returned to the client 11a, 11b which initiated the query. Other data herein may correspond to data from any number of sources which are accessible to the computing environment 6, other than the components COMP(n,mn), and may be in the same format, or a different format, to the record data record(kn,m). For example, a read query may additionally return data, whether in the same or a different format to the record data record(kn,m), from one or more conventional databases (not shown) communicatively connected to, or forming part of, the computing environment 6. As described hereinbefore for each item of record data record(kn,m), the computing environment 6 tracks the instantiation 7, 8 which it belongs to (i.e. was generated within) and the time periods for which it is valid. An item of record data record(kn,m) which is not valid will have an associated end time tendcorresponding to an actual time and date. A valid item of record data record(kn,m) will have an associated start time tstartand either no end time tend, or an end time tend set to a predetermined value denoting ongoing validity such as, for example, -1 or the value “NaN” which the computing environment 6 uses for undefined numbers (e.g. divide by zero). The valid range of an item of record data record(kn,m), extending tstart≤ t < tendmay be stored in metadata of the item of record data record(kn,m), as part of the item of record data record(kn,m) itself (see data items data(kn,m) in relation to Figures 12 to 18B), or may be associated with the item of record data record(kn,m) in any other suitable way (for example look-up tables and so forth) Deleted items of record data record(kn,m) are not actually deleted or removed from the corresponding component COMP(n,mn), and may be excluded from the results list in a variety of ways. One approach used in some methods of the present specification is to denote deletion of an item of record data record(kn,m) by setting the corresponding end time tendto a time that the item of record data record(kn,m) is deleted. In this way, that item of record data record(kn,m) is not valid from the deletion time onwards, and is directly excluded from the relevant timeline(s) (see steps S15, S18, S21 and / or S23 described hereinafter). An alternative approach used in other methods of the present specification is to leave a deleted item of record data record(kn,m) with an end time tend unset or denoting ongoing validity, and to tag / flag it as deleted, for example using metadata or a deleted flag included in the item of record data record(kn,m) itself. In this second approach, the end time tend of the record data record(kn,m) being deleted is again set to the deletion time. The difference is that a new item of record data record(Kn,m+1) is added, having a range of validity which starts from the deletion time and does not end. It is the new item of record data record(Kn,m+1) which is flagged / tagged as deleted. The data contents of the deleted record data record(kn,m) may be copied across to the new item of record data record(Kn,m+1), but this is not essential. In this way, the new item of record data record(Kn,m+1) corresponding to the deleted item of record data record(kn,m) will remain valid on the relevant timeline(s), but is instead excluded from the results list using a filter of the read query, for example to exclude items of record data record(kn,m) flagged / tagged as deleted. Advantageously, this second approach may make it easier to retrieve deleted items, as a read query could be run without the filter to exclude deleted items. Timeline of a sandbox instantiation The concept of the timeline for each sandbox instantiation 8 shall be explained with particular reference to Figures 7 and 8. Items of record data record(kn,m) belonging to (i.e. generated within) the originating sandbox instantiation 8 (step S14|Yes) and which are valid up to a time of the read query (step S15|Yes) belong to the timeline and are added to the results list (step S6). As explained hereinbefore, an item of record data record(kn,m) is valid up to a time of the read query (step S15) provided that the corresponding end time tendis unset, set to the predetermined value denoting ongoing validity, or the end time tendis after the time of the read query. The case that the end time tendis after the time of the read query does not arise when the read query is made corresponding to the present time. However, the computing environment 6 may support making a read query corresponding to a query time set in the past. This is possible because record data is the computing environment 6 is only modified using copy on write processes. Such “time-travel” functionality allows a user to investigate the state of any instantiation 7, 8 they have access permissions to at any time point from the past up to the present, and is a further benefit of the computing environment 6 of particular which may be of particular use for debugging, data audits and so forth. Referring briefly to the examples shown in Figure 5, a read query in the first example sandbox instantiation 81 at time t4 would return all valid items of record data record(kn,m) belonging to the first example sandbox instantiation 81, from the respective creation time tcreate= t1up to the query time t4. In the case that an item of record data record(kn,m) does not belong to the originating sandbox instantiation 8 (step S14|No), the consideration is divided into two streams in dependence upon whether the originating sandbox instantiation 8 is a direct descendant of the main instantiation 7 (step S16). In the case that the originating sandbox instantiation 8 is a direct descendant of the main instantiation 7 (step S16|Yes), it is checked whether: a) the currently considered item of record data record(kn,m) belongs to (i.e. was generated within) the main instantiation 7 (step S17|Yes); b) the currently considered item of record data record(kn,m) is valid up to the creation time tcreate of the originating sandbox instantiation 8 (step S18|Yes); and c) the currently considered item of record data record(kn,m) is not superseded by an item of record data record(k ≠ kn,m) belonging to the originating sandbox instantiation 8 (step S19|No); Referring in particular to Figure 8, the step of determining whether a currently considered item of record data record(kn,m) is superseded (step S19) is shown in further detail. When the currently considered item of record data record(kn,m) belongs to the main instantiation 7 (step S17|Yes) and is valid up to the creation time tcreateof the originating sandbox instantiation 8 (step S18|Yes), the test for being superseded (step S19) is whether there is newer record data record(k ≠ kn,m) which corresponds to the same object and belonging to the originating sandbox instantiation 8 (step S24). In other words, has the item of record data record(kn,m) been replaced by record(k ≠ kn,m) in the originating sandbox instantiation 8. For example, if an item of record data record(kn,m) corresponds to a database entry, and in the originating sandbox instantiation 8 one or more fields of that database entry have been modified (corresponding to the newer version record(k ≠ kn,m)). If there is no superseding record data record(k ≠ kn,m) (step S24|No) (i.e. if all of the conditions a), b) and c) hereinbefore are met), then the currently considered item of record data record(kn,m) belongs to the timeline of the originating sandbox instantiation and is added to the results list (step S6). Referring again to Figure 7 in particular, in the case that currently considered item of record data record(kn,m) does not belong to the main instantiation 7 or the directly descendent originating sandbox instantiation 8 (steps S14|No followed by S16|Yes then by S17|No), that item of record data record(kn,m) is evidently not on the timeline of the originating sandbox instantiation 8, and the process moves to step S7. Referring briefly to the examples shown in Figure 5, a read query in the first example sandbox instantiation 81at time t4would return all valid items of record data record(kn,m) which belong to the main instantiation 7 up to, but not including, the creation time tcreate= t1of the first example sandbox instantiation 81, provided they are not superseded by items of newer record data record(k≠kn,m) in the first example sandbox instantiation 81. Any items of record data record(kn,m) created in the main instantiation at a time equal to or after the creation time tcreate= t1will not be on the timeline of the first example sandbox instantiation 81, and will not be visible in the results list returned by a read query carried out in the in the first example sandbox instantiation 81. Similarly, any items of record data record(kn,m) created in the descendent second example sandbox instantiation 82will not be on the timeline of the first example sandbox instantiation 81, and will not be visible in the results list returned by a read query carried out in the in the first example sandbox instantiation 81. In the case that the originating instantiation 8 is descendant from the main instantiation 7 via a sequence of one or more antecedent sandbox instantiations 8 (step S16|No), it is tested whether the currently considered item of record data record(kn,m) belongs to the main instantiation (step S20). If the currently considered item of record data record(kn,m) belongs to the main instantiation (step S20|Yes), it is checked: d) that the currently considered item of record data record(kn,m) is valid up to the creation time tcreateof an earliest antecedent sandbox instantiation 8 of the sequence of one or more antecedent sandbox instantiations (step S21|Yes); and e) referring again to Figure 8, that the currently considered item of record data record(kn,m) is not superseded by a newer item of record data record(k ≠ kn,m) corresponding to the same object and belonging to one of the sequence of one or more antecedent sandbox instantiations 8 (step S25|No) or belonging to the originating sandbox instantiation 8 (step S24|No). If there is no superseding record data record(k ≠ kn,m) (step S25|No followed by step S24|No), i.e. if both the conditions d) and e) hereinbefore are met, then the currently considered item of record data record(kn,m) belongs to the timeline of the originating sandbox instantiation and is added to the results list (step S6). The test d) may also be expressed as whether the currently considered item of record data record(kn,m) is valid up to the point whether the sequence of one or more antecedent sandbox instantiations 8 leading to the originating sandbox instantiation diverged (or “branched”) from the main instantiation 7. The creation time tcreate of the earliest antecedent sandbox instantiation 8 represents the latest record data record(kn,m) from the main instantiation 7 which is visible to the originating sandbox instantiation. Referring briefly to the examples shown in Figure 5, a read query in the second example sandbox instantiation 82at time t4would return all valid items of record data record(kn,m) which belong to the main instantiation 7 up to, but not including, the creation time tcreate= t1of the first example sandbox instantiation 81, provided they are not superseded by items of newer record data record(k≠kn,m) in the first or second example sandbox instantiations 81, 82. Similarly, a read query in the ninth example sandbox instantiation 89at time t17would return all valid items of record data record(kn,m) which belong to the main instantiation 7 up to, but not including, the creation time tcreate= t15of the eighth example sandbox instantiation 88, provided they are not superseded by items of newer record data record(k≠kn,m) in the eighth or ninth example sandbox instantiations 88, 89. Referring again to Figure 7, if the currently considered item of record data record(kn,m) does not belong to the main instantiation (step S20|No), it is checked: f) that the currently considered item of record data record(kn,m) belongs to a sandbox instantiation 8 of the sequence of antecedent sandbox instantiations 8 (step S22|Yes). In other words, a sandbox instantiation 8 which is both an antecedent of the originating sandbox instantiation 8 and a descendant from the main instantiation 7. g) that the currently considered item of record data record(kn,m) is valid up to the earlier of (step S23|Yes): o the creation time tcreateof the next antecedent sandbox instantiation 8 in the sequence of one or more antecedent sandbox instantiations 8; and o the creation time tcreateof the originating sandbox instantiation 8; h) referring again to Figure 8, that the currently considered item of record data record(kn,m) is not superseded by a newer item of record data record(k ≠ kn,m) corresponding to the same object and belonging to the originating sandbox instantiation or a later sandbox instantiation 8 in the sequence of one or more antecedent sandbox instantiations. If there is no superseding record data record(k ≠ kn,m) (step S26|No followed by S24|No) (i.e. if all the conditions f), g) and h) hereinbefore are met), then the currently considered item of record data record(kn,m) belongs to the timeline of the originating sandbox instantiation and is added to the results list (step S6). Referring briefly to the examples shown in Figure 5, the eleventh example sandbox instantiation 811descends from the main instantiation via a sequence consisting of (in order) the eighth example sandbox instantiation 88and the tenth example sandbox instantiation 810. A read query in the eleventh example sandbox instantiation 811at time t21would return: ^ items of record data record(kn,m) belonging to the main instantiation 7 and valid up to, but not including, the creation time tcreate = t15 of the eighth example sandbox instantiation 88(in this example, this is the first creation time tcreateon the timeline checked step S21 in Figure 7), provided said items of record data record(kn,m) are not superseded by newer items of record data record(k≠kn,m) belonging to any of the eighth 88, tenth 810or eleventh 811sandbox instantiations (noting that the ninth sandbox instantiation 89does not belong to the timeline); ^ items of record data record(kn,m) belonging to the eighth example sandbox instantiation 88, and valid up to, but not including, the creation time tcreate= t18of the tenth example sandbox instantiation 810(see step S23 in Figure 7, the “next” creation time tcreatemeans the next in the sequence of sandbox instantiation, not chronologically next), provided said items of record data record(kn,m) are not superseded by newer items of record data record(k≠kn,m) belonging to either of the tenth 810and eleventh 811sandbox instantiations; ^ items of record data record(kn,m) belonging to the tenth example sandbox instantiation 810, and valid up to, but not including, the creation time tcreate= t19of the eleventh example sandbox instantiation 811, provided said items of record data record(kn,m) are not superseded by newer items of record data record(k≠kn,m) belonging to the eleventh 811sandbox instantiation; and ^ items of record data record(kn,m) belonging to the eleventh example sandbox instantiation 811, and valid up to the time of the read query. The preceding definitions of the timeline of an originating sandbox instantiation 8 in which a read query is conducted are closed. In other words, the timeline of an originating sandbox instantiation 8 only includes record data record(kn,m) satisfying one of the conditions explained hereinbefore with reference to Figures 6 to 8 (or as further elaborated hereinafter in relation to, for example, Figure 15). It may sometimes be helpful to refer to the timeline of the main instantiation 7, which herein simply means any items of record data record(kn,m) which belong to the main instantiation 7 and which are valid at the time of a read query. Operations within the computing environment All modifications made to any component COMP(n,mn) of the computing environment 6 use a copy-on-write process. In other words, record data record(kn,m) stored in component COMP(n,mn) is never actually deleted, even though it may cease to be valid (or may be flagged as deleted) and / or may be superseded on the timelines of one or more descendent sandbox instantiations 8. Herein, a client 11a, 11b accessing an active instantiation 7, 8 and making a modification of a component COMP(n,mn) at a modification time tmodmay encompass one or more of: i) Adding a new item of record data record(kn,m) corresponding to a new object (i.e. no corresponding prior items of record data record(kn,m)); ii) Replacing or modifying an existing item of record data record(kn,m) from the relevant timeline; iii) Deleting an existing item of record data record(kn,m); iv) Changing the structure of the component COMP(n,mn); v) Changing a rule 18 (whether for all sandbox instantiations or a subset); vi) Changing a permission of a component COMP(n,mn) or a subset of record data record(n,mn) within the component COMP(n,mn). The active instantiation 7, 8 may be the main instantiation 7 or any sandbox instantiation 8 which the client 11a, 11b in question has permission to modify. Cases v) and / or vi) may be implemented comparably with existing computing environments 6. Alternatively, the rules 18 and / or permissions may be treated as record data record(n,mn) and handled as described for cases i) to iv) hereinafter. Case i) is relatively straightforward. If the relevant component COMP(n,mn) includes a number Kn,m=K0of items of record data record(kn,m), the new item of record data record(K0+1) is added to the component COMP(n,mn), belonging to the active instantiation 7, 8 and having a start time equal to the modification time tstart= tmod. For example, if a client 11a, 11b accessing the main instantiation 7 generated a new item of record data record(kn,m) corresponding to a new object, it would belong to the main instantiation 7. Whereas, if the client 11a, 11b was instead accessing the first example sandbox instantiation 81shown in Figure 5, the new item of record data record(kn,m) corresponding to the new object would belong to the first example sandbox instantiation 81. Case ii) depends on whether the existing item of record data record(kn,m) belongs to the active instantiation 7,8 or an antecedent instantiation 7, 8 (if any). If the existing item of record data record(kn,m) belongs to the active instantiation 7, 8, the end time tendof the existing item of record data record(kn,m) is set equal to the modification time tend= tmod. The existing item of record data record(kn,m) is not deleted and remains stored in the corresponding component COMP(n,mn). A new item of record data record(K0+1) is added to the component COMP(n,mn) to store the modified data, which belongs to the active instantiation 7, 8 and has a start time equal to the modification time tstart= tmod. The number K0denotes the number of items of record data record(kn,m) just before addition of new item of record data record(K0+1). If the existing item of record data record(kn,m) belongs to an antecedent instantiation 7, 8, which is only possible when the active instantiation is a sandbox instantiation 8, the end time tendof the existing item of record data record(kn,m) is not set. This is because that existing item of record data record(kn,m) may remain valid within its own instantiation 7,8 or a separate sandbox instantiation depending therefrom. Instead, a new item of record data record(K0+1) is added to the component COMP(n,mn) to store the modified data, which belongs to the active sandbox instantiation 8 and has a start time equal to the modification time tstart= tmod. The new item of record data record(K0+1) will automatically supersede the existing item of record data record(kn,m) on the timeline of the active sandbox instantiation 8 (as explained hereinbefore). Case iii) depends on whether the deleted item of record data record(kn,m) belongs to the active instantiation 7,8 or an antecedent instantiation 7, 8 (if any). Case iii), deletion, also depends on whether deletions are being implemented by removing the deleted item of record data record(kn,m) from the relevant timeline or by flagging it as deleted (see preceding discussion). Both approaches shall be explained. Deletion implemented by removal from relevant timeline: If the deleted item of record data record(kn,m) belongs to the active instantiation 7, 8, the end time tendof the existing item of record data record(kn,m) is simply set equal to the modification time tend= tmod. The deleted item of record data record(kn,m) will therefore not be valid at and after the modification time tmod, and will consequently not be part of the timeline of the active instantiation 7, 8 or descendent sandbox instantiations 8 branching from the active instantiation 7, 8 after the modification time tmod. However, if the deleted item of record data record(kn,m) belongs to an antecedent instantiation 7, 8, which is only possible when the active instantiation is a sandbox instantiation 8, the end time tendof the deleted item of record data record(kn,m) is not set. This is because that item of record data record(kn,m) should only be deleted from the perspective of the active sandbox instantiation 8 (and any descendent sandbox instantiations which branch off after the modification time tmod). A new item of record data record(K0+1) is added to the component COMP(n,mn), belonging to the active instantiation, and the end time is set to the modification time tend= tmod. The new item of record data record(K0+1) may copy the deleted item of record data record(kn,m), or may be a largely or entirely empty “stub” record. The new item of record data record(K0+1) will supersede the deleted item of record data record(kn,m) so that is excluded from the timeline of the active sandbox instantiation 8, and the new item of record data record(K0+1) will also be excluded from the timeline because it is not valid at and after the modification time tmod. Deletion implemented by flagging deleted status: If the deleted item of record data record(kn,m) belongs to the active instantiation 7, 8, the end time tendof the existing item of record data record(kn,m) is set in the same way as the preceding case, i.e. tend= tmod. However, a new item of record data record(K0+1) is also added corresponding to the active instantiation 7, 8, with a start time tstart= tmodand an end time tend corresponding to ongoing validity. The data contents of the deleted item of record data record(kn,m) may be copied across to the new item of record data record(K0+1), though this is not essential. The new item of record data record(K0+1) is flagged as deleted, for example in associated metadata or in the item of record data record(K0+1) itself. From the perspective of the timeline of the active instantiation, the deleted item of record data record(K0+1) remains valid at and after the modification time tmod. The new item of record data record(K0+1) will supersede the item of record data record(kn,m) on the timeline of the active sandbox instantiation 8 (and any descendants), and will be excluded from the results list returned by a read query which includes a filter to remove items of record data record(kn,m) which are flagged as deleted. Similarly, if the deleted item of record data record(kn,m) belongs to an antecedent instantiation 7, 8, which is only possible when the active instantiation is a sandbox instantiation 8, the deleted item of record data record(kn,m) is not flagged as deleted and the end time tendis not set. This is because that item of record data record(kn,m) should only be deleted from the perspective of the active sandbox instantiation 8 (and any descendent sandbox instantiations which branch off after the modification time tmod). A new item of record data record(K0+1) is added to the component COMP(n,mn), belonging to the active sandbox instantiation, and flagged as deleted. The new item of record data record(K0+1) may copy the deleted item of record data record(kn,m), or may be a largely or entirely empty “stub” record. The new item of record data record(K0+1) will supersede the item of record data record(kn,m) on the timeline of the active sandbox instantiation 8 (and any descendants), and will be excluded from the results list returned by a read query which includes a filter to remove items of record data record(kn,m) which are flagged as deleted. Versioning of components and timelines Case iv) concerns changing the structure of a component COMP(n,mn) within an active instantiation 7, 8, or changing the structure of record data record(kn,m) stored therein. The active instantiation may be the main instantiation 7 or any sandbox instantiation 8 which a client 11a, 11b is permitted to access and modify. In response to changing the structure of the component of the COMP(n,mn) having an existing number M0(positive integer ≥ 1) of versions, and / or changing a structure of one or more items of record data record(kn,m) stored therein, a new version of that component COMP(n,M0+1) is generated at a version update time Tver. It should be noted that the previous version COMP(n,mn) being modified does not have to be the previously highest numbered version COMP(n,M0) (and often will not be). The new version of the component COMP(n,M0+1) is also associated with the active instantiation in order that sandbox instantiations 8 descendent from the active instantiation 7, 8 will access the correct version of the component COMP(n,mn). The new version of the component COMP(n,M0+1) may be associated with the active instantiation 7, 8 in which it was generated in any suitable way, including but not limited to: using the metadata of the new version of the component COMP(n,M0+1), using an additional item of record data record(kn,m) stored in the new version COMP(n,M0+1); using a separate look-up table stored as record data record(kn,m) stored in another component comp(h≠n,mh) (with h an integer), and so forth. When generating the new version of a component COMP(n,M0+1), it may be necessary to copy and / or modify the stored record data record(kn,m) of the previous version. Re- versioning of components may also be of a first type termed “compatible”, in which no specific logic or function is required in order to modify the record data record(kn,m) of the previous version before storing to the new version COMP(n,M0+1), or a second type termed “incompatible”, in which a specific logic or function is needed to adapt the record data record(kn,m). Further details are explained hereinafter in relation to the examples shown in Figures 18A and 18B. Subsequently when a read query is made in any given sandbox instantiation 8, if the version update time tverand the associated instantiation 7,8 (in which the new version COMP(n,M0+1) was generated) belong to the timeline of the read query originating sandbox 8, the read query will return record data of the new version of the component COMP(n,M0+1). However, if the version update time tverand the associated instantiation 7,8 do not belong to the timeline of the read query originating sandbox 8, then the new version COMP(n,M0+1) does not exist from the perspective of the read query originating sandbox 8, and the read query will return record data record(kn,m) from whichever version of the component COMP(n,mn) is the most recent on the respective timeline. In the specific case of the main instantiation 7, it should be noted that the main instantiation 7 does not necessarily see the highest version number Mnfor a particular component COMP(n,mn). In particular, a new version COMP(n,M0+1) generated in a sandbox instantiation 8 will not be visible to the main instantiation 7 unless and until that sandbox instantiation 8 is merged with the main instantiation. In general, multiple versions of the same component COMP(n,mn) may exist in parallel at the same time, belonging to the timelines of different sandbox instantiations 8 and / or the main instantiation 7. Record data record(kn,m) may continue to be added or otherwise modified to any version of the component COMP(n,mn). Examples of sandbox instantiations Referring again to Figure 5, the preceding discussions will be further understood by discussing examples of use cases corresponding to the examples of the first to eleventh example sandbox instantiations 81, …, 811. Sandbox instantiation for feature development The first example sandbox instantiation 81is generated at time tcreate= t1within the main instantiation 7. The first example sandbox instantiation 81is merged with the main instantiation 7 at time t5, and deleted shortly afterwards. Although not shown in Figure 5, if a descendant sandbox instantiation (for example the second example sandbox instantiation 82) persists after deletion of the first example sandbox instantiation 81, it may still need to refer to record data record(kn,m) of the first example sandbox instantiation 81. In this example, record data record(kn,m) of the first example sandbox instantiation 81is not actually deleted when the first example sandbox instantiation 81 is deleted. Instead, after being deleted, it is no longer possible to directly access and / or modify the first example sandbox instantiation 81. By contrast, in other examples record data record(kn,m) of a deleted sandbox instantiation 8 (for example the first example sandbox instantiation 81) may be deleted to save memory / storage capacity provided that all descendant sandbox instantiations 8 (for example the second example sandbox instantiation 82) have also been deleted and / or if all record data record(kn,m) inherited from the deleted sandbox instantiation 8 has been deleted and / or superseded in all descendant sandbox instantiations 8. Although explained by reference to the first example sandbox instantiation 81, the option to delete record data record(kn,m) created within a deleted sandbox instantiation 8 once it is no longer referenced by any other active sandbox instantiation 8 is generally applicable. The first example sandbox instantiation 81 represents an a simple example of using a sandbox instantiation 8, for example to test and review a feature (similarly to the examples 8a to 8d shown in Figure 2), the developed feature will by denoted “feature A” for the purposes of discussing the Figure 5 examples. When the first example sandbox instantiation 81is first generated, no items of record data record(kn,m) belong to it. Items of record data record(kn,m) are added to the first example sandbox instantiation 81when a user inputs entirely new data or modifies a previous item of record data record(k≠kn,m) which belongs to its timeline. In the case of modification at a modification time of, for example tmod= t2, the previous item of record data record(k≠kn,m) corresponding to that object is not deleted. If the previous item of record data record(k≠kn,m) belongs to the first example sandbox instantiation 81, its end time tendis set to the modification time tmodso that it is not valid any longer, and the new item of record data record(kn,m) is added to the first example sandbox instantiation 81with validity from the start time tstart= tmod. If the previous item of record data record(k≠kn,m) belongs to the main instantiation 7, it is not modified. The new item of record data record(kn,m) is added to the first example sandbox instantiation 81with validity from the start time tstart= tmod. Subsequently, on the timeline of the first example sandbox instantiation 81the previous item of record data record(k≠kn,m) is superseded. At the time t5 of merging the first sandbox instantiation 81 with the main instantiation 7, the timeline of the first sandbox instantiation 81includes: ^ all valid record data record(kn,m) belonging to the first sandbox instantiation 81; and ^ all record data record(kn,m) belonging to the main instantiation 7 which was valid up to the creation time tcreate= t1and which has not been modified or deleted in the first sandbox instantiation 81(i.e. not superseded). Nested sandbox instantiation for testing and review In order to test and review the feature developed in the first example sandbox instantiation 81, a second example sandbox instantiation 82is created at time t2within the first example sandbox instantiation 81. This scenario shows how a nested sandbox instantiation 82can be used to test and review a developed feature, such as feature A, without affecting the sandbox instantiation 81that was used for the development. For example, testing data could only be generated in the second example sandbox instantiation 82. The second sandbox instantiation 82 also illustrates that it is not necessary for every sandbox instantiation 8 to be merged with the main instantiation 7 or another sandbox instantiation. The second example sandbox instantiation 82is never merged because it is only used for testing and reviewing purposes. Once this is completed, the merge of the first example sandbox 81with the main instantiation 7 may proceed. The second example sandbox instantiation 82is no longer needed and may be deleted. At time t4, just before it is deleted, the timeline of the second sandbox instantiation 82includes: ^ all valid record data record(kn,m) belonging to the second sandbox instantiation 82; ^ all record data record(kn,m) belonging to the first example sandbox instantiation 81which was valid up to the creation time tcreate= t2of the second example sandbox instantiation 82, and which has not been modified or deleted in the second sandbox instantiation 82(i.e. not superseded); and ^ all record data record(kn,m) belonging to the main instantiation 7 which was valid up to the creation time tcreate = t1 of the first example sandbox instantiation 81, and which has not been or deleted in the first 81or second 82example sandbox (i.e. not superseded). Developing two Features Independently This use case is illustrated by the third 83, fourth 84and fifth 85example sandbox instantiations. A second feature, denoted “feature B”, is developed in the third example sandbox instantiation 83. Separately, a third feature, denoted “feature C”, is developed in the fourth example sandbox 84instantiation. The development of feature B in the third example sandbox instantiation 83cannot see the record data record(kn,m) relating to the development of feature C in the fourth example sandbox instantiation 84and vice versa. In order to test the combination of features B and C together without risking disruption to the main instantiation 7, the fifth example sandbox instantiation 85is generated within the main instantiation at time tcreate= t6. Just after creating the fifth example sandbox instantiation 85, its timeline contains all record data record(kn,m) belonging to the main instantiation 7 which was valid up to the creation time tcreate= t6of the fifth example sandbox instantiation 85. This is advantageous because the testing of features B and C can be conducted in relation to the most up-to-date data of the main instantiation 7. For example, since development of feature A was started at t3and of feature B at t4, in addition to any changes made directly to the main instantiation 7, the first example sandbox instantiation 81was also merged with the main instantiation 7 at time t5to introduce feature A. Feature B is introduced by merging the third example sandbox instantiation 83with the fifth example sandbox instantiation 85at time t7, and similarly feature C is introduced by merging the fourth example sandbox instantiation 84with the fifth example sandbox instantiation 85at time t8. Preferably, both merge operations use the conflict detection processes described hereinafter in relation to Figure 9 to 11 so that if, for example, the same record data record(kn,m) from the main instantiation 7 has been modified differently when developing features B and C, the conflict will be automatically detected. Additionally, because the fifth example sandbox instantiation 85sees record data record(kn,m) of the main instantiation 7 up to time t6, any conflict with record data record(kn,m) modified in developing feature A in the first example sandbox instantiation 81 will also be detected. After testing (quality assurance evaluation) of features B and C in combination (in the up-to-date context of the main instantiation 7 up to time t6), features B and C may be implemented into the main instantiation 7 by separately merging the third example sandbox instantiation 83into the main instantiation 7 at time t9and then merging the fourth example sandbox instantiation 84into the main instantiation 7 at time t11. In an alternative approach to that illustrated in Figure 5, the fifth example sandbox instantiation 85may be directly merged with the main instantiation 7 once testing is completed. Whilst the third 83and fourth 84example sandbox instantiations are both deleted shortly after being merged with the main instantiation 7, the fifth example sandbox instantiation 85 is not deleted. In this way, if required the fifth example sandbox instantiation 85may be accessed again for further testing purposes. In this example, each of the third 83and fourth 84example sandbox instantiations were merged twice, within different target instantiations (once each with the fifth example sandbox instantiation 85and with the main instantiation 7). In general, a sandbox instantiation 8 may be merged any number of times with the main instantiation 7 or any other sandbox instantiation 8, and may be modified or not between different merge operations. Rebasing a Sandbox The sixth example sandbox instantiation 86is generated within the main instantiation 7 at time tcreate= t10, for the purpose of developing a further feature, denoted “feature D” for the purposes of discussing the Figure 5 examples. During the development of feature D, at time t11, feature C developed in the fourth sandbox example 84was merged with the main instantiation 7. Consequently, since the timeline of the sixth example sandbox instantiation 86only sees the record data record(kn,m) of the main instantiation up to tcreate= t10, the sixth example sandbox instantiation 86does not include the changes relating to feature C. In order to test feature D developed in the sixth sandbox instantiation with the current state of the main instantiation 7 (including features A to C, and also any other changes to the main instantiation since time t10), the sixth example sandbox instantiation 86can be rebased to time t12. This is accomplished by generating a new, seventh sandbox instantiation 87at time tcreate= t12, followed by merging the sixth example sandbox instantiation 86with the seventh example sandbox instantiation 87at time t13. Consequently, the seventh example sandbox instantiation 87has a timeline including the current state of the main instantiation 7 up to time t12(unless superseded), as well as changes made in the sixth sandbox instantiation 86when developing feature D. One significant advantage is that any conflict, for example between record data record(kn,m) modified in the fourth example sandbox instantiation 84and differently modified in the sixth example sandbox instantiation, may be detected and resolved in the seventh sandbox instantiation 87, before the seventh sandbox instantiation 87is merged with the main instantiation 7 at time t14to introduce feature D. Developing Features in Nested Sandboxes An eighth example sandbox instantiation 88is generated within the main instantiation 7 at time tcreate= t15for the purpose of developing a complex denoted “feature E” for the purposes of this discussion, and which includes sub-features denoted “E-1” and “E-2” respectively. A ninth example sandbox instantiation 89is created within the eighth example sandbox instantiation 88at time tcreate= t16, for the purpose of developing sub-feature E-1. It can be helpful to develop sub-features isolated within respective sandbox instantiations, which permits that the sub feature E-1 is only merged to main development of feature E in the eighth example sandbox instantiation when it is ready. In this case, the ninth example sandbox instantiation 89is merged with the eighth example sandbox instantiation 88at time t17. Afterwards, another nested sandbox instantiation, the tenth example sandbox instantiation 810is created within the eighth example sandbox instantiation 88at time tcreate= t18for the purpose of developing the second sub-feature E-2. After sub-feature E-2 is completed, the tenth example sandbox instantiation 810is merged with the eighth example sandbox instantiation 88at time t20. At time t21, the fully completed feature E is incorporated into the main instantiation 7 by merging the eighth sandbox instantiation 88with the main instantiation 7. Each of the ninth 89and tenth 810example sandbox instantiations is deleted shortly after the respective merge with the eighth example sandbox instantiation 88. The eighth example sandbox instantiation 88is not deleted to potentially allow for further development of feature E later on. In general, any number of sandbox instantiation may be nested. For example, an eleventh example sandbox instantiation 811is generated within the tenth example sandbox instantiation 810at time tcreate= t19. For example, if there were two options for how to approach implementing sub-feature E-2 and only time in the short term to try one, the eleventh example sandbox instantiation 811could be generated and left open to allow returning to try the alternative approach to sub-feature E-2 when developers have time. The eleventh example sandbox instantiation 811 is then descendent from the main instantiation 7 via the sequence of antecedent sandboxes including, in order, the eighth example sandbox instantiation 88and the tenth example sandbox instantiation 810. At the end of the period illustrated in Figure 5, the timeline of the eleventh sandbox instantiation 811includes: ^ all valid record data record(kn,m) belonging to the eleventh sandbox instantiation 811; ^ all record data record(kn,m) belonging to the tenth example sandbox instantiation 810which was valid up to the creation time tcreate= t19of the eleventh example sandbox instantiation 811, and which has not been modified or deleted in the eleventh sandbox instantiation 811(i.e. not superseded); and ^ all record data record(kn,m) belonging to the eighth example sandbox instantiation 88which was valid up to the creation time tcreate= t18of the tenth example sandbox instantiation 810, and which has not been modified or deleted in the tenth 810and / or eleventh 811sandbox instantiations (i.e. not superseded). It should be noted that this does include the record data record(kn,m) merged in from the ninth example sandbox instantiation 89at time t17; and ^ all record data record(kn,m) belonging to the main instantiation 7 which was valid up to the creation time tcreate= t15of the eighth example sandbox instantiation 88, and which has not been modified or deleted in the eighth 88(directly of via merge with the ninth 89) tenth 810, and / or eleventh 811example sandbox instantiations (i.e. not superseded). In general, sandbox instantiations 8 may be deleted when desired, for example, once the purpose they were created for is concluded, as illustrated in Figure 5 for the first 81, second 82, third 83, fourth 84, sixth 86, seventh 87, ninth 89and tenth 810examples of sandbox instantiation. However, as illustrated by the fifth 85, eighth 88and eleventh 811example sandbox instantiations do not need to be deleted. It is preferable that sandboxes be deleted (or at least transferred to long-term archival storage such as a tape) once no longer required, for example in response to a user command, or following a predetermined period of inactivity in which a particular sandbox instantiation 8 is not accessed by any client 11a, 11b and where that sandbox instantiation 8 is not an antecedent of any actively used sandboxes. If it was desired to delete a first sandbox instantiation 8 without deleting a second sandbox instantiation 8 descended from the first, one option would be to merge the first sandbox instantiation 8 into the second before deleting. Even if deleted or archived, a unique identifier of any given sandbox instantiation 8 is not re-used. Global components / data The computing environment 6 may additionally include one or more global components, denoted herein as COMPglobal(not specifically illustrated). Each global component COMPglobalstores one or more items of global data denoted herein as recordglobal. A read query executed within a sandbox instantiation 8 returns a union (see step S13 in Figure 6) of the record data record(kn,m) belonging to the timeline of that sandbox instantiation 8 (at described hereinbefore) with and any global data recordglobalwhich also matches the query. For example, a global component COMPglobalcould be used to store a listing of all users who are authorised to use the computing environment 6, and the level of access (e.g. read, read and write etc) which each user is permitted to the main instantiation 7 and each sandbox instantiation 8. This is an example of a component COMPglobalwhich you want to maintain in a single version across all instantiations 7, 8 and corresponding timelines. Otherwise, sandbox instantiations 8 having out of date user permissions could present a significant security vulnerability. Each global component COMPglobalincludes metadata, and each global component COMPglobaland / or the metadata thereof may be structured the same as a component COMP(n,mn) and / or the metadata thereof. Global data recordglobalmay be structured the same as record data record(kn,m), or may be structured differently. Any modification of global data recordglobalstored in a global component COMPglobalmay be visible to every sandbox instantiation 8 which has access permissions to the that global component COMPglobal(for example, using conventional user-access control methods). Metadata of each global component COMPglobalmay specify whether or not the global data recordglobalstored therein may be modified within a subset, or all, of the sandbox instantiations 8. A global component COMPglobalmay store a first set of global data recordglobalwhich may be modified within some, or all, of the sandbox instantiations 8, and a second set of global data recordglobalwhich is not permitted to be modified except from within the main instantiation 7. In addition to, or instead of, global components COMPglobal, the computing environment 6 may be configured such that one or more of the components COMP(n,mn) may also store global data recordglobalin addition to record data record(kn,m). This may be implemented by keeping the global data recordglobalentirely distinct from the items of record data record(kn,m). Alternatively, the global data recordglobalmay be implemented as an item of record data record(kn,m) having an associated flag indicating its status as global data recordglobal(for example in metadata or as part of the structure of the item of record data record(kn,m) itself). Output suppression Some components COMP(n,mn) may be configured to generate one or more outputs, for example when executed in the main instantiation 7. The one or more outputs may include, for example, outputs generated by record data record(kn,m) in the form of executable computer code stored in the component COMP(n,mn). Examples of outputs from components COMP(n,mn) may include, without being limited to: a) An output in the form of a message for sending to a recipient external to the computing environment 6; b) An output in the form of a control signal for controlling one or more devices, actuators, peripheries and so forth (not shown), which are communicatively coupled to the computing environment 6; or c) An output in the form of a command or request to modify record data record(kn,m) of one or more other components COMP(h≠n,mn). When dealing with such components COMP(n,mn) in a sandbox instantiation 8, it may be desirable to suppress any or all of the outputs which may be generated from that component. This is implemented in the computing environment 6 using the metadata of the components COMP(n,mn). The metadata of a particular component (or version thereof) COMP(n,mn) may store one or more output suppression flags corresponding to any or all of the one or more outputs generated by that component COMP(n,mn). For example, if several items of record data record(kn,m) take the form of executable computer code (or scripts or similar) which generate outputs, an output suppression flag corresponding to each may be included in the metadata of component COMP(n,mn). If the output suppression flag corresponding to a particular output is set to true, then that output will be suppressed or re-directed. The output suppression flags, if set, may apply in any sandbox instantiation 8, i.e. those outputs will always be suppressed or re- directed except when generated within the main instantiation 7. Additionally or alternatively, output suppression flags may be selectively set, for example by a user via client 11a, 11b, to enable or disable particular outputs for particular sandbox instantiation(s) 8. Suppressing or re-directing one or more outputs corresponding to output suppression flags may include, or take the form of, adding those outputs to an output queue. The output queue may be stored in the given component COMP(n,mn) or in a different component COMP(h≠n,mn) (potentially a global component discussed hereinafter). Suppressed or re-directed outputs generated and added to an output queue may be held unless and until the sandbox instantiation 8 they were generated in is merged with the main instantiation 7 (or into a different sandbox instantiation 8 in which the one or more outputs are not flagged for suppression). There are a variety of situations in which the described output suppression would be desirable. Referring to case a) hereinbefore, in a context in which a storage environment (not shown) is monitored by a number of different sensors (sensors) detecting parameters such as temperature, humidity, light levels and so forth. A component COMP(n,mn) stores record data record(kn,m) in the form of drivers for each sensor and detection logic for interpreting the sensor data. An alert message may be triggered by sensor readings which exceed pre-set tolerances, for example corresponding to conditions in the storage environment which would cause damage / degradation of stored products. If it is desired to modify or improve the detection logic, for example to add or replace one of the sensors, a sandbox instantiation 8 may be generated and run in parallel with the main instantiation 7 to allow testing the modified / improved detection logic. For example, if the sensor outputs are flagged as global data, then the modified / improved detection logic may be applied to live date from within the sandbox instantiation 8. For a transitional period, it may be desirable to suppress alert messages generated within the sandbox instantiation 8 so that potentially erroneous messages are sent to a log instead of to personnel responsible for the storage environment. Once a sufficient period has elapsed to determine that the modified / improved detection logic is functioning as intended, the sandbox instantiation 8 may be merged with the main instantiation 7 to complete the upgrade. Referring to case b) hereinbefore, consider a robot arm (not shown) used in an assembly line. A component COMP(n,mn) may store record data record(kn,m) corresponding to a control program which controls the movements of the robot arm (not shown) based on inputs received from other components COMP(h≠n,mn) corresponding to sensors (machine vision sensors and so forth). A sandbox instantiation 8 may be generated to test a patch to the control program intended to avoid failure in response to a rare set of circumstances. However, it is advantageous to confirm that the patch does not lead to unexpected and unintended behaviour in other situations (as can be a common issue when patching computer programs to fix a specific issue). Rather than applying the patch directly to the main instantiation 7, the patch is applied in the sandbox instantiation 8. Setting the components COMP(h≠n,mn) corresponding to sensors, or at least the sensor outputs, as global data allows running the patch in tandem based on live data. In this situation, the outputs to the robot arm (for example servo motors and so forth) generated by the patch within the sandbox instantiation 8 should be suppressed, for example re-directed to a log (e.g. stored as record data record(kn,m) of the same or a different component COMP(n,mn)). Once it is confirmed that the patch of the rare issue does not inadvertently generate other issues (for example by comparing the logged outputs to those from the main instantiation 7), the sandbox instantiation 8 may be merged with the main instantiation to implement the patch. Referring to case c), utility of output suppression is not limited to the preceding examples in which live, global data is being analysed. For example, a user may be working in a sandbox instantiation 8 on a component COMP(n,mn) corresponding to a function of generating an e-mail to customers and contacts of the organisation operating the computing environment 6. For example, the user may be working to update rules about which e-mail addresses to include. In this example, it is desirable to suppress the generation and sending of the e-mail unless and until the sandbox instantiation used to develop the updated rules is merged with the main instantiation 7. This will prevent, for example, inadvertent data breaches / unwanted e-mails being generated during testing of the updated rules. Merging sandbox instantiations Merging a sandbox instantiation 8 with the main instantiation 7 or a different sandbox instantiation 8 has been discussed in the preceding examples, and the processes for conducting such a merge shall be explained with reference also to Figures 9 to 11. In the following discussion, the sandbox instantiation 8 being merged will be referred to as the “source” instantiation, and the target of the merge will be referred to as the “target” instantiation. Any sandbox instantiation 8 may be selected as the source instantiation. The target instantiation may be selected as the main instantiation 7 or any sandbox instantiation 8 which is not the source instantiation. A merge is initiated at a merge time tmerge. A set of source record data SOURCE is collated which includes all record data record(kn,m) across all components COMP(n,mn) which belong to the timeline of the source instantiation (step S27). In the case where deletions are performed by setting the end time tend, this corresponds to the results list of a read query executed in the source instantiation without any filters. In the case where deletions are performed by adding new, superseding items of record data record(K0+1) which are flagged as deleted, this corresponds to the results list of a read query executed in the source instantiation with a single filter to remove items of record data record(kn,m) flagged as deleted. If the target instantiation is the main instantiation 7 (step S28|Yes), then a set of target record data TARGET is collated which includes all record data record(kn,m) across all components COMP(n,mn) which belong to the main instantiation 7 and are valid (and not deleted) up to the merge time tmerge(step S29). As explained hereinbefore, these conditions are effectively to a timeline for the main instantiation 7. If the target instantiation is not the main instantiation 7 (step S28|No), i.e. the target instantiation is a sandbox instantiation 8 which is not the source instantiation, the set of target record data TARGET is collated which includes all record data record(kn,m) across all components COMP(n,mn) which belong to the timeline of the target instantiation (step S30). In relation to deleted items, the same considerations apply as to the set of source record data SOURCE. Optionally, the sets of record data SOURCE and TARGET are compared to detect and resolve potential conflicts between items of record data record(kn,m) which correspond to the same object of the computing environment 6 (step S31). Whilst optional, it is typically preferable to implement conflict detection, and an example method is explained with reference to Figures 10 and 11. Record data of the target instantiation is modified based on comparing the set of source record data SOURCE to the set of target record data TARGET (step S32). If the optional conflict detection (step S31) was carried out, the step of modifying the record data of the target instantiation (step S32) may include implementing conflict resolutions determined during the conflict detection step (step S31). Modifying the record data of the target instantiation (step S32) may include any combination of: ^ adding record data record(kn,m) from the set of source record data SOURCE to the target instantiation; ^ replacing record data record(kn,m) from the target instantiation with record data record(kn,m) from the set of source record data SOURCE; ^ combining record data record(kn,m) from the target instantiation with record data record(kn,m) from the set of source record data SOURCE; and / or ^ deleting record data record(kn,m) from the target instantiation which is absent from the set of source record data SOURCE. In any of the preceding cases, modification of record data record(kn,m) in the target instantiation is carried out using the copy on write processes described hereinbefore. In the simplest case, modifying the record data of the target instantiation (step S32) takes the form of simply overwriting the record data of the target instantiation using that of the source instantiation. In this case, the set of source record data SOURCE is compared to the set of target record data TARGET and: ^ If both sets SOURCE, TARGET contain the identical item of record data record(kn,m), nothing is done. This corresponds to situations in which the source instantiation descends from the target instantiation, or both source and target instantiation descend from a common antecedent instantiation (any pair of sandbox instantiations will have at least the main instantiation 7as common antecedent), and where the item of record data record(kn,m) has not been modified on either timeline. ^ If the set of source record data SOURCE contains an item of record data record(kn,m) corresponding to an object, for example a database entry for an employee or a source code file corresponding to a particular function, and the set of target record data TARGET contains no items of record data record(kn,m) corresponding to that object (i.e. database entry for the same employee or source code file for the particular function), the item of record data record(kn,m) from the source instantiation is added to the target instantiation with validity from the merge time tmerge(note that both items or record data record(kn,m) will be stored in the same component COMP(n,mn), and will differ in being associated with different instantiations). ^ If the set of source record data SOURCE contains an item of record data record(kn,m) corresponding to an object and the set of target record data TARGET contains an item of record data record(kn,m) corresponding to that object, then the item of record data record(kn,m) from the set of source record data SOURCE is used to replace the item of record data record(kn,m) in the target instantiation with validity from the merge time tmerge. ^ If the set of target record data TARGET contains an item of record data record(kn,m) corresponding to an object and the set of source record data SOURCE contains no items of record data record(kn,m) corresponding to that object, the item of record data record(kn,m) from the set of target record data TARGET is deleted from the target instantiation, effective from the merge time tmerge. Although relatively straightforward to implement and appropriate for some computing use cases, the benefits of the computing environment 6 may be more fully realised by including a conflict detection (and resolution) process (step S31). The computing environment 6 can be configured, in response to detecting one or more conflicts, to resolve each conflict according to pre-set rules and / or by prompting a user to decide how to resolve that conflict via the client 11a, 11b. Conflict detection and resolution Referring in particular to Figure 10, an example of a conflict detection process (step S31) is shown. Starting with the first item of record data record(kn,m) in the SOURCE set (step S33), each item of record data record(kn,m) in the SOURCE set is checked to determine whether the TARGET set includes an item of record data record(kn,m) corresponding to the same object (step S34). If the TARGET set does not include an item of record data record(kn,m) corresponding to the same object (step S34|No), is it checked whether the timeline of the target instantiation did include an item of record data record(kn,m) corresponding to the same object which was deleted before the merge time tmerge(step S35). In the case where deletions are handled by setting the end time tendcorresponding to an item of record data record(kn,m), checking for deleted items of record data may be done by checking the component COMP(n,mn) corresponding to the currently considered item of record data record(kn,m) from the SOURCE set to determine whether it includes any items of record data record(kn,m) corresponding to the same object and belonging to the target instantiation or an antecedent instantiation thereof. In the case where deletions are performed by adding new, superseding items of record data record(K0+1) which are flagged as deleted,, the presence of deleted items of record data record(kn,m) may be picked up by executing a read query in the target instantiation without any filters, and comparing the results list to the TARGET set. If an item of record data record(kn,m) corresponding to the same object was not deleted from the timeline of the target instantiation (step S35|No), in other words if the currently considered item of record data record(kn,m) from the SOURCE set corresponds to an object which has never had any corresponding data in the target instantiation, the currently considered item of record data record(kn,m) from the SOURCE set is flagged to be added to the target instantiation with validity from tstart= tmergeat the modification stage (step S32). If there are more items of record data record(kn,m) in the SOURCE set (step S40|Yes), then the next item of record data record(kn,m) in the SOURCE set is considered (step S41). If an item of record data record(kn,m) corresponding to the same object was deleted from the timeline of the target instantiation (step S35|Yes), then the currently considered item of record data record(kn,m) from the SOURCE set is flagged for conflict resolution (step S37). If there are more items of record data record(kn,m) in the SOURCE set (step S40|Yes), then the next item of record data record(kn,m) in the SOURCE set is considered (step S41). For example, if an item of record data record(kn,m) from the SOURCE set corresponds to an object, for example a sensor or an employee record, yet the record data record(kn,m) corresponding to that sensor or employee record has been deleted from the target instantiation, it may not be appropriate to simply add the data back to the target instantiation after it was specifically deleted. This is why this situation should preferably be flagged for conflict resolution. If the TARGET set does include an item of record data record(kn,m) corresponding to the same object as the currently considered item of record data record(kn,m) from the SOURCE set (step S34|Yes), is it checked whether the item of record data record(kn,m) from the TARGET set has been modified since the source instantiation diverged from the target instantiation at a common antecedent instantiation (step S38). Any pair of sandbox instantiations 8 which both contain an item of record data record(kn,m) corresponding to the same object should have a common antecedent instantiation (at least the main instantiation 7) containing an item of record data record(kn,m) corresponding to that object. However, if there is not the case (which may indicate data corruption / tampering), then the currently considered item of record data record(kn,m) from the SOURCE set will additionally be flagged as a conflict (not shown in Figure 10 for visual clarity and brevity). For example, referring again to Figure 5, consider the first example sandbox instantiation 81and an item of record data record(kn,m) belonging to the main instantiation 7 prior to time t1. If the object corresponding to the record data record(kn,m) is modified in the first example sandbox instantiation 81at time t3, new record data record(K0+1) is added as described hereinbefore (which will be considered in the SOURCE set). In this case, the item of record data record(kn,m) from the TARGET set has not been modified since the source instantiation 81diverged from the target instantiation 7 at a common antecedent instantiation 7 (step S38|No). However, if the item of record data record(kn,m) was also modified in the main instantiation 7 between time t1and the merge time tmerge= t5, then the item of record data record(kn,m) from the TARGET set has been modified since the source instantiation diverged from the target instantiation (step S38|Yes). If the item of record data record(kn,m) from the TARGET set has not been modified (step S38|No), then there is no conflict and the currently considered item of record data record(kn,m) from the SOURCE set is flagged to replace the item of record data record(kn,m) from the TARGET set (step S39) at the modification stage (step S32), with validity from tstart= tmerge. However, if the item of record data record(kn,m) from the TARGET set has been modified (step S38|Yes), then the currently considered item of record data record(kn,m) from the SOURCE set is flagged for conflict resolution (step S37). In either case, if there are more items of record data record(kn,m) in the SOURCE set (step S40|Yes), then the next item of record data record(kn,m) in the SOURCE set is considered (step S41). Once all items of record data record(kn,m) from the SOURCE set have been checked against the TARGET set (step S40|No), an optional reverse-conflict check may be performed to check all items of record data record(kn,m) from the TARGET against the SOURCE set for further types of potential conflict (step S42). Although optional, a reverse-conflict check is preferably included to improve quality and data integrity of the merge. An example of the reverse-conflict checking shall be explained with particular reference to Figure 11. Starting with the first item of record data record(kn,m) in the TARGET set (step S45), each item of record data record(kn,m) in the TARGET set is checked to determine whether the SOURCE set includes an item of record data record(kn,m) corresponding to the same object (step S46). If the SOURCE set includes an item of record data record(kn,m) corresponding to the same object (step S46|Yes), then potential conflicts will have been checked already in the preceding steps (see step S38). If there are more items of record data record(kn,m) in the TARGET set (step S51|Yes), then the next item of record data record(kn,m) in the TARGET set is considered (step S52). If the SOURCE set does not include an item of record data record(kn,m) corresponding to the same object (step S46|No), is it checked whether the timeline of the source instantiation did previously include an item of record data record(kn,m) corresponding to the same object which was deleted before the merge time tmerge(step S47). In the case where deletions are handled by setting the end time tendcorresponding to an item of record data record(kn,m), checking for deleted items of record data may be done by checking the component COMP(n,mn) corresponding to the currently considered item of record data record(kn,m) from the TARGET set to determine whether it includes any items of record data record(kn,m) corresponding to the same object and belonging to the source instantiation or an antecedent instantiation thereof. In the case where deletions are performed by flagging items of record data record(kn,m) as deleted, the presence of deleted items of record data record(kn,m) may be picked up by executing a read query in the source instantiation without any filters, and comparing the results list to the SOURCE set. If an item of record data record(kn,m) corresponding to the same object was not deleted from the timeline of the source instantiation (step S47|No), in other words if the currently considered item of record data record(kn,m) from the TARGET set corresponds to an object which has never had any corresponding data in the source instantiation, then no action is required for the currently considered item of record data record(kn,m) from the TARGET set. If there are more items of record data record(kn,m) in the TARGET set (step S51|Yes), then the next item of record data record(kn,m) in the TARGET set is considered (step S52). If an item of record data record(kn,m) corresponding to the same object as the currently considered item of record data record(kn,m) from the TARGET set was deleted from the timeline of the source instantiation (step S47|Yes), then it is checked whether the currently considered item of record data record(kn,m) from the TARGET set has been modified since the source instantiation diverged from the target instantiation at a common antecedent instantiation (step S48). If the item of record data record(kn,m) from the TARGET set has not been modified (step S48|No), then there is no conflict and the currently considered item of record data record(kn,m) from the TARGET set is flagged for deletion from the target instantiation at time tmerge (step S59) at the modification stage (step S32). However, if the item of record data record(kn,m) from the TARGET set has been modified (step S48|Yes), then the currently considered item of record data record(kn,m) from the SOURCE set is flagged for conflict resolution (step S50). In either case, if there are more items of record data record(kn,m) in the TARGET set (step S51|Yes), then the next item of record data record(kn,m) in the TARGET set is considered (step S52). Referring again to Figure 10, once all items of record data record(kn,m) from the SOURCE set (and optionally the TARGET set) have been checked for conflicts and flagged appropriately, a resolution action is assigned to every item of record data record(kn,m) flagged as a conflict (step S43). Conflicts may be resolved using pre-set rules, which may be fixed or user editable / selectable. For example, a user may be prompted, via the client 11a, 11b, to set conflict resolution rules, or select / adapt from a number of template conflict resolution rules, at the time of initiating the merge tmerge(or even earlier, at the time of generating the source sandbox instantiation). Alternatively, or in cases where pre-set rules are not applicable to a particular conflict, the user may be prompted, via the client 11a, 11b, to determine how they wish to resolve that conflict. A mixture of pre-set rules and user inputs may be used. For example, a user may configure a merge so that some types of conflict will be resolved using pre-set rules, but may wish to be prompted to manually resolve other types of conflict. For example, a user may wish to override any deletion of an item of record data record(kn,m) in the target instantiation (flagged at step S37 arriving from step S35|Yes), but may wish to be prompted to make a manual decision in every case where an item of record data record(kn,m) in the target instantiation has been modified since a common antecedent instantiation (flagged at step S37 arriving from step S38|Yes). Actions to resolve a particular flagged conflict may include any of (without limitation): ^ Using an item of record data record(kn,m) from the SOURCE set to replace an item of record data record(kn,m) from the TARGET set corresponding to the same object; ^ Keeping an item of record data record(kn,m) from the TARGET set corresponding to the same object as an item of record data record(kn,m) from the SOURCE set; ^ Deleting an item of record data record(kn,m) from the TARGET set which does not correspond to any item of record data record(kn,m) from the SOURCE set; ^ Generating a new item of record data record(kn,m) in the target instantiation based on (for example combining) items of record data record(kn,m) from the SOURCE and TARGET sets corresponding to the same object; ^ In the case of a conflict which a user is prompted to resolve via the client 11a, 11b, generating a new item of record data record(kn,m) in the target instantiation based on input via the client 11a, 11b. Once actions to resolve all flagged conflicts have been set, a further, optional check may be made to check that the set of planned actions (additions, deletions, replacements, and so forth) will not violate one or more rules 18 applicable to one or more of the components COMP(n,mn) and / or the computing environment more generally (step S44). Examples of rules 18 which the computing environment 6 may be configured to enforce for one or more components may include, for example: ^ A rule 18 requiring uniqueness of a subset of items of record data record(kn,m) within each instantiation (for example customer or employee data, MAC addresses for computers or sensors and so forth); ^ A rule 18 requiring numerical or non-numerical values within respective ranges, (for example, parameters set for a peripheral device controlled by the computing environment 6 should be within allowed ranges). A rule enforcing uniqueness may be applicable to record data record(kn,m) from the main instantiation 7 and to record data record(kn,m) on the timeline of every sandbox instantiation 8. However, since different sandbox instantiations 8 may see different record data record(kn,m) on their respective timelines, record data need not be unique in the component COMP(n,mn) overall, and the rule may be applied to each timeline separately. If the planned changes will contravene one of more applicable rules 18 (step S44), then control may be returned to step S43 to obtain user input to resolve any conflicts with the rules 18. Otherwise, the planned changes are actioned to complete the merge of the source instantiation with the target instantiation by modifying the record data record(kn,m) of the target instantiation (step S32). The examples of conflicts detected and resolved in the methods illustrated in Figures 10 and 11 are not exhaustive, and any number of additional conflict conditions may be defined by a user or administrator of the computing environment 6. Equally, if any of the illustrated types of conflict is not considered problematic for a given application, detection and resolution of such conflict(s) may be omitted in other examples. The preceding examples relate to an implementation in which the computing environment 6 is configured to check for, and determine how to resolve, all conflicts before starting to modify record data record(kn,m) in the target instantiation. This approach is preferable in a case where it is desired to check for adherence to any rules 18 enforced on the data (step S44), since such a check is harder to perform without advance knowledge of all planned changes. However, in other implementations, it may be preferred to immediately start updating record data record(kn,m) of the target instantiation, and to check for and resolve each conflict as it arises (including prompting the user via client 11a, 11b is needed). Re-basing of sandbox instantiations An example of re-basing a sandbox instantiation 8 was explained previously in relation to the sixth 86and seventh 87sandbox instantiations illustrated in Figure 5. With further reference to the preceding description of merging, further examples of re- basing sandbox instantiations 8 may be explained. In the general case, a sandbox instantiation 8 may be re-based relative to base instantiation which can be the main instantiation 7 or any other sandbox instantiation 8. Re-basing an active sandbox instantiation 8 relative to a base instantiation involves: ^ Generating a new sandbox instantiation 8 within the base instantiation; and ^ Merging the active sandbox instantiation 8 with the new sandbox instantiation 8 (i.e. the active sandbox instantiation 8 is the source instantiation and the new sandbox instantiation 8 is the target instantiation). The user can then continue working within the new sandbox instantiation 8, which will include the record data record(kn,m) from the timelines of both active sandbox instantiation 8 and the base instantiation. The user may select the base instantiation, via client 11a, 11b, either before or at the time of the re-base request. For security reasons, the computing environment 6 should preferably be configured so that the user requesting the re-basing must have at least read access to the base instantiation. There are a variety of different examples in which re-basing may be useful. In a first case, as explained hereinbefore in relation to the sixth 86and seventh 87sandbox instantiations illustrated in Figure 5, it may be desired to re-base a sandbox instantiation 8 relative to the main instantiation 7. This permits, for example, a development being carried out in the sandbox instantiation 8 to be tested relative to an up-to-date state of the main instantiation. Another use case for re-basing is when the base instantiation is a first sandbox instantiation 8a and the active instantiation is a second sandbox instantiation 8b which is directly descendent from the first sandbox instantiation 8a. In this case, there are two approaches, based on whether or not the first sandbox instantiation 8a has been re- based. For example, if the first sandbox instantiation 8a has not been re-based, then we can re-base the second sandbox instantiation 8b by generating a new, third sandbox instantiation 8c which is directly descendent from the first sandbox instantiation 8a. The second sandbox instantiation 8b is then merged with the third sandbox instantiation 8c to complete the re-basing. However, if the first sandbox instantiation 8a has been re-based, for example relative to the main instantiation 7 (or an antecedent sandbox instantiation 8), to generate a fourth sandbox instantiation 8d, we need to handle re-basing of the second sandbox instantiation 8b differently in order to capture all changes. In this case, the third sandbox instantiation 8c is generated within the fourth sandbox instantiation 8d, and the second sandbox instantiation 8b is then merged with the third sandbox instantiation 8c to complete the re-basing. Example of record data format Referring also to Figure 12, one example format of record data record(kn,m) is shown. In this example the record data record(kn,m) of each component COMP(n,mn) includes, or takes the form of, a number Kn,mof data items. Denoting the kn,mthof Kn,mdata items as data(kn,m), each data item data(kn,m) includes: ^ a data payload PL; ^ a data identifier ID; ^ a sandbox identifier SBID; ^ a start time tstart; and ^ an end time tend; Each component COMP(n,mn) also includes metadata 19, in addition to the Kn,m, of data items. Note that herein, Kn,mis not fixed over time, and simply denotes the number of data items data(kn,m) at the time that component COMP(n,mn) is accessed. The number Kn,mincreases time a new data item data(kn,m) is added or a pre- existing data item data(kn,m) modified, due to the copy-on-write processes implemented by the computing environment 6. For the purposes of determining sandbox instantiation 8 timelines, each data item data(kn,m) is valid at or after the start time tstartand before the end time tend. Ongoing validity of a data item data(kn,m) may be denoted by omitting the end time tendor by setting the end time tendto a predetermined ongoing validity value such as, for example, 0, -1, NaN, for any other value not needed to define conventional and practical times within the computing environment 6. Hereinafter, we denote the data payload PL corresponding to the kn,mthof Kn,mdata items data(kn,m) as data(kn,m).PL, and similarly for the data identifier data(kn,m).ID and the sandbox identifier data(kn,m).SBID. The start tstartand end tendtimes are written in this example as data(kn,m).ValidRange = [tstart, tend), with the square bracket “[” denoting that the range is inclusive of tstart and the rounded bracket “)” denoting that the range is exclusive of tend. The data items data(n,mn) are one example of an item of record data record(kn,m), and are described herein to further illustrate the methods described hereinbefore. Other types structures may be used for items of record data record(kn,m), provided that whichever specific implementation is used allows tracking the relevant instantiation (main 7 or sandbox 8) to which it belongs, the time range over which it is valid, and the object within the computing environment 6 that it corresponds to. Each data item data(kn,m) corresponds to an object such as, for example, a data table having a number of fields and any number of rows, script files, compiled code forming a library, a dynamic link library, a configuration file, source code, executable computer code, embeddings used by a machine learning (ML) large language model (LLM), graphical design elements including templates and images, or any other type of object capable of definition in a computing environment 6 and storable to a computer readable medium. The data payload data(kn,m).PL stores the information of the object, and the data identifier data(kn,m).ID stores a reference which corresponds to the object. Each data identifier ID is unique to the corresponding object, but each data identifier ID may, and generally will, be stored in a number of data items data(kn,m) which all correspond to the same object, for example at different times and / or in different sandbox instantiations 8. The data identifier data(kn,m).ID of a data item data(kn,m) may also be part of the data payload data(kn,m).PL of that data item data(kn,m). In some data items data(kn,m), the data identifier data(kn,m).ID may be derived based on all or part of the data payload data(kn,m).PL of a data item data(kn,m). For example if a given component COMP(n,mn) is storing a list of networked sensors, the MAC address of each sensor may be both part of the data payload data(kn,m).PL and also serve as the data identifier data(kn,m).ID. In another example, the data payload data(kn,m).PL may take the form of a database entry having a number of fields, and the data identifier data(kn,m).ID may be formed by combining two or more of the fields. The sandbox identifier data(kn,m).SBID of a data item data(kn,m) identifies which sandbox instantiation 8 that data item data(kn,m) belongs to. In this example, membership of the main instantiation 7 is identified by omitting the sandbox identifier data(kn,m).SBID. Alternatively, membership of the main instantiation 7 may be identified by using a predetermined value of sandbox identifier data(kn,m).SBID to denote the main instantiation such as, for example, SBID = 0, -1, NaN and so forth. A predetermined value used to denote the main instantiation 7 may in general be any value which can be reserved and prohibited from use to denote a sandbox instantiation 8. Optionally, each data item data(kn,m) may also include a flag, data(kn,m).Global which is set to true if that data item data(kn,m) corresponds to global data recordglobal, and false otherwise. In a case where all of the data items data(kn,m) of a component COMP(n,mn) are flagged data(kn,m).Global = true, then that component COMP(n,mn) is a global component COMPglobal. In a case where one or more data items data(kn,m) of a component COMP(n,mn) are flagged as global, those data items having data(kn,m).Global = true may also be described as “global data items”. Alternatively, instead of flagging global data within individual data items data(kn,m) using the flags data(kn,m).Global = true, global data recordglobalmay instead take form of combining one or more data items data(kn,m) with corresponding flags stored in the metadata 19 of the corresponding component COMP(n,mn). Whenever a new data item data(kn,m) is generated within an active instantiation, whether the main instantiation 7 a sandbox instantiation 8, and whether the data identifier data(kn,m).ID to an entirely new object, or to replacing (i.e. superseding) a pre-existing data item data(kn,m) from the timeline of the active instantiation: ^ the data payload data(kn,m).PL stores the object information / data; ^ the data identifier data(kn,m).ID corresponds to the object represented; ^ the sandbox identifier data(kn,m).SBID is set to correspond to the active instantiation in which the data item data(kn,m) was generated (with membership of the main instantiation 7 denoted by omission or a predetermined value as explained hereinbefore); ^ The start time tstartis set to the time that the new data item data(kn,m) is generated; ^ The end time tendof a new data item data(kn,m) is typically not set, or is set to the predetermined value denoting ongoing validity (except in particular cases described hereinafter). The data items data(kn,m) are not limited to the elements shown in Figure 12 and described hereinbefore, and may include any number of additional elements. For example a deletion flag data(kn,m).deleted as discussed herein as an alternative to handling deletions using the valid time range data(kn,m).ValidRange to exclude deleted items from the relevant timeline. The metadata 19 may include any information described herein and relating to the component COMP(n,mn) overall and / or specific data items data(kn,m) stored therein. For example, the metadata may include flag(s) denoting global status of the component COMP(n,mn) or one of more data items data(kn,m) stored therein, and / or output suppression flags described hereinbefore. If the structure of data items data(kn,m) within a component COMP(n,mn) is changed, or if the structure of the metadata 19 is changed, a new version COMP(n,Mn+1) is generated, as described elsewhere in this specification. Sandbox table Referring also to Figure 13, a sandbox table is illustrated. The sandbox table represents one option to keep track of the creation times tcreateand relationships (antecedent / descendent) between sandbox instantiations 8. The specific sandbox table illustrated in Figure 13 corresponds to the first to eleventh example sandbox instantiations 81, …, 811shown in Figure 5. The sandbox table includes a number of rows equal to the number of sandbox instantiations. The sandbox table also includes at least three columns. The first column holds the sandbox identifier SBID value corresponding to each sandbox instantiation 8. For example, because they are created in order, the first to eleventh example sandbox instantiations 81, …, 811have SBIDs 1 to 11 respectively. If a sandbox instantiation 8 is deleted, for example the second example sandbox instantiation 82is deleted between times t4and t5shown in Figure 5, the corresponding sandbox identifier SBID value is not re-used. The second column of the sandbox table includes the creation time tcreatecorresponding to each sandbox instantiation 8. For example, the first example sandbox instantiation 81 is generated at time t1 illustrate in Figure 5, the fifth example sandbox instantiation 85is generated at time t6, the ninth example sandbox instantiation 89is generated at time t16and so forth. The third column of the sandbox table stores the SBID value of the instantiation within which each sandbox instantiation 8 was generated, denoted the ParentSBID. In this example, the system non-a-number (NaN) value is used to denote the main instantiation 7 (other possible values include 0, -1 and so forth). For example, the first example sandbox instantiation 81is generated within the main instantiation 7, the second example sandbox instantiation 82is generated within the first example sandbox instantiation 81, the eleventh example sandbox instantiation 811is generated within the tenth example sandbox instantiation, and so forth. In general, the sandbox table may store a number J (positive integer) of rows, though this does not mean that there are J sandbox instantiations, since some may have been deleted once no longer needed. As mentioned hereinbefore, the respective rows and SBID values of deleted sandbox instantiations 8 are not re-used. In some implementations of the computing environment 6, the sandbox table may be stored separately from the components COMP(n,mn). Alternatively, the sandbox table may be stored as a global component COMPglobal(since all instantiations 7, 8 need to see this information), with a global data item data(kn,m) corresponding to each row of the sandbox table. The precise format and / or storage location of the sandbox table is not essential, provided that the computing environment 6 has access to the relevant information as shown in Figure 13. Worked example of data items Referring also to Figure 14, a worked example of data items data(kn,m) is shown. The example shown in Figure 14 is a table of computer systems 9 within an organisation, used in this case to help manage their network configuration. Each row of the table in Figure 14 corresponds to a single data item data(kn,m). In this example, the data payload data(kn,m).PL includes four fields: “Row”, “User name”, “MAC Address” and “Location”. The field of “User name” is also used as the data identifier data(kn,m).ID, corresponding uniquely in this example to objects in the form of assigned users for particular computer systems 9. Alternatively, if the configuration was to be based around objects in the form of the particular computer systems 9, the “MAC Address” fields could be used as the data identifiers data(kn,m).ID instead. In this example, membership of the main instantiation 7 is denoted by the predetermined value data(kn,m).SBID = NaN. Start tstartand end tendtimes are presented in day-month-year-time format, and ongoing validity is denoted by the predetermined value tend= NaN. In this example, each data item data(kn,m) includes a global flag data(kn,m).Global. The computing environment 6 corresponding to the table of Figure 14 is configured to handle deletions by setting an end time tendto exclude deleted items for subsequent evaluations of the relevant timeline. Data item data(1) corresponds to a user J.SMITH, and is not valid at the present time because the end time tendhas been set to a specific value. In fact, the data item data(1) has been superseded in the main instantiation 7 by data item data(7), because at an earlier time the specific computer system 9 assigned to user J.SMITH has been replaced. Data item data(2) corresponds to a user P.MASON, and remains valid in the main instantiation 7 at the present time because the end time tendis set to the predetermined value denoting ongoing validity. Data item data(3) corresponds to a user MAIN.SERVER corresponding to the organisations’ central server, and has the global flag set to data(3).Global = true because in this example it is required to be visible to all sandbox instantiations 8. Data items data(4) and data(5) have the same value in the “MAC Address” field but correspond to different users. Specifically, the computer system 9 was initially assigned to a user Y.BROWN, who subsequently left and consequently the data item data(4) was deleted by setting the end time tend. At a later date, data item data(5) was added for a new user A.MILLER, who was assigned the computer system 9 previously used by Y.BROWN, and data item data(5) remains valid up to the present time. The table of Figure 14 illustrates a scenario in which the IT department of the organisation is coordinating an upgrade project to replace every current users’ computer system 9 with an upgraded model. The IT department has generated a separate sandbox instantiation 8 for each location where they have an office. A first sandbox instantiation 8a corresponds to their London office and has SBID=1. A second sandbox instantiation 8b corresponds to their Manchester office and has SBID=2. A third sandbox instantiation 8b corresponds to their Cardiff office and has SBID=3. Before the first sandbox instantiation 8a was opened, the component COMP(n,mn) storing the table of Figure 14 included a number Kn,m= K0data items data(1), …, data(K0). In the respective sandbox instantiations 8a,8b, 8c, the IT department have updated the details for each user to correspond to their assigned new computer system – there would also be corresponding data added to other components COMP(h≠n,mh) in each sandbox instantiation 8a, 8b, 8a (not shown in Figure 14), enabling the IT department to setup and test each new computer system 9 in their office, whilst the users continue to logon to their current computer systems 9 in the main instantiation 7. Once the IT department has setup each new computer system 9 and tested it within the respective sandbox instantiation 8a, 8b, 8c, they intended to visit each office in turn to physically replace the computer systems 9. They will then trigger a merge of the respective sandbox instantiation 8a, 8b, 8c to update the main instantiation 7 and bring all the new computer systems 9 for the corresponding office online at once (having also obtained the benefits of testing the interoperation of each new computer system 9 with their internal network in the sandbox instantiations 8a, 8b, 8c first). After setting up the sandbox instantiations 8a, 8b, 8c, it is subsequently remembered that one of the new computer systems 9 (with MAC address 51-C6-97-62-D3-7D) has slightly different hardware because user J.SMITH needs to carry out specific work. In data item data(K0+3), this computer system 9 was erroneously assigned to the user P.MASON. This is corrected by adding a new data item data(K0+5) to the first sandbox instantiation 8a, and setting the end time tendof the superseded item data(K0+1) so that this data item data(K0+1) is no longer valid in the timeline of the first sandbox instantiation 8a. Similarly, new data item data(K0+6) is added to the second sandbox instantiation 8b, and the end time tendof the superseded item data(K0+3) is set so that this data item data(K0+3) is no longer valid in the timeline of the second sandbox instantiation 8b. Referring in particular to data item data(K0+2), this data item data(K0+2) illustrates deletion of the data item data(6) within the first sandbox instantiation 8a. For example, the user K.FARRIER has recently left and there is no need to replace their computer system 9. Consequently, this user is deleted in the first sandbox instantiation 8a. The data item data(6) in the main instantiation 7 is not deleted, as explained hereinbefore. Instead, new data item data(K0+2) is generated, the data payload data(6).PL is copied over, to the new data item data(K0+2), and the end time tendof the new data item data(K0+2) is set to the deletion time of this user. Read request using data items Referring again to Figure 6, and referring also to Figure 15, the evaluation of data items data(kn,m) belonging to the timeline of a query originating sandbox instantiation 8 in response to a read query is illustrated. The method illustrated in Figure 15 concerns read queries conducting in a query originating sandbox instantiation 8. As previously, read queries in the main instantiation 7 are handled differently, and in the context of data items data(kn,m) will return any data items data(kn,m) which match the read query, which have sandbox identifier data(kn,m).SBID corresponding to the main instantiation 7 and data(kn,m).ValidRange indicating validity at the time of a read query. This may sometimes be referred to as the timeline of the main instantiation 7. Returning to the process illustrated in Figure 15, the loop on index kn,mand consideration of matching to the ready query (steps S3, S4, S7 and S8) are substantially the same as shown in Figure 6 and described in relation thereto. The read query may filter based on any information of the data item data(kn,m), and is not limited to only filtering based on data payload data(kn,m).PL, for example filtering may also be conducted based on the data identifier data(kn,m).ID, the sandbox identifier data(kn,m).SBID, the validity range data(kn,m).ValidRange, and / or any further optional flags / elements of the data item data(kn,m) such as global status flags data(kn,m).Global, deletion status flags and so forth. If the currently considered data item data(kn,m) matches the query (step S4|Yes), it is considered whether the data item data(kn,m) belongs to the query originating sandbox instantiation 8 or an antecedent thereof (step S52). This is evaluated based on the sandbox identifier data(kn,m).SBID, in combination with the sandbox table, which contains records of all sandbox instantiation antecedences. If the currently considered data item data(kn,m) does not belong to the query originating sandbox instantiation 8 or an antecedent thereof (step S52)|No), then consideration passes to the next data item data(kn,m+1), if any (steps S7 and S8). This can arise because data items data(kn,m) from all sandbox instantiations 8 are stored in the same component COMP and corresponds to the case of data items data(kn,m) belonging to sandbox 8 independent from the query originating sandbox instantiation 8. If the currently considered data item data(kn,m) belongs to the query originating sandbox instantiation 8 or an antecedent thereof (step S52)|Yes), then it is considered whether the data item data(kn,m) is valid at the query time tquery(step S53). There are several cases to be in dependence on whether the sandbox identifier data(kn,m).SBID indicates of: i) the query originating sandbox instantiation 8; ii) an antecedent sandbox instantiation of a sequence of one or more antecedent sandbox instantiations 8 via which the query originating sandbox instantiation 8 descends from the main instantiation 7; or iii) the main instantiation 7. These different cases have been described hereinbefore in relation to Figure 6, and the additional description hereinafter shall be limited to the specifics when applied in the context of data items data(kn,m) structure as illustrated in Figure 12 and described hereinbefore. Case i), i.e. record data record(kn,m) belonging to the query originating sandbox instantiation 8 which is valid up to a time tqueryof the read query, corresponds to data items data(kn,m): ^ which have a sandbox identifier data(kn,m).SBID corresponding to the query originating sandbox instantiation 8; and ^ which have an end time tendthat denotes ongoing validity (by being omitted or by equalling the predetermined value). Case ii), i.e. record data record(kn,m) belonging to an antecedent sandbox instantiation 8 of the sequence of one or more antecedent sandbox instantiations 8 and belonging to the timeline of the query originating sandbox instantiation 8, corresponds, for each antecedent sandbox instantiation 8 in the sequence, to data items data(kn,m): ^ which have a sandbox identifier data(kn,m).SBID corresponding to that antecedent sandbox instantiation 8; ^ which have a start time tstartbefore the creation time tcreateof the next antecedent sandbox instantiation 8 in the sequence; and ^ which have an end time tendthat: o creation time tcreateof the next antecedent sandbox instantiation 8 in the sequence; or o denotes ongoing validity. Case iii), i.e. record data record(kn,m) belonging to the main instantiation 7 and belonging to the timeline of the query originating sandbox instantiation 8, corresponds to data items data(kn,m): ^ which have a sandbox identifier data(kn,m).SBID corresponding to the main instantiation (for example by being omitted or by being set to the predetermined value); ^ which have a start time tstart: o when the query originating sandbox instantiation 8 is a direct descendant, before the creation time tcreateof the query originating sandbox instantiation 8; o when the query originating sandbox instantiation 8 descends via a sequence of one of more antecedent sandbox instantiations 8, before the creation time tcreateof the first antecedent sandbox instantiation 8 in the sequence; and ^ which have an end time tendthat: o is after the applicable creation time tcreate(same as the previous condition); or o denotes ongoing validity. If the currently considered data item data(kn,m) is not valid at the query time tquery(step S53|No), then the next data item data(kn,m+1) (if any) is considered (steps S7 and S8). If the currently considered data item data(kn,m) is valid at the query time tquery(step S53|Yes), then it is checked whether the results list already contains a data item data(k≠kn,m) corresponding to the same object (step S54). This is checked by comparing the data identifier data(kn,m).ID against the data identifiers data(k≠kn,m).ID of data items data(k≠kn,m) previously added to the results list. If the results list does not contain a data item data(k≠kn,m) corresponding to the same data identifier data(kn,m).ID as the currently considered data item data(kn,m) (step S54|No), then the currently considered data item data(kn,m) is added to the results list (step S55) and the next data item data(kn,m+1) (if any) is considered (steps S7 and S8). If the results list already contains a data item data(k≠kn,m) corresponding to the same data identifier data(kn,m).ID as the currently considered data item data(kn,m) (step S54|Yes), then it is considered whether the currently considered data item data(kn,m) supersedes the data item data(k≠kn,m) already in the results listing (step S56). There are two cases to be considered, in dependence on whether the sandbox identifier data(kn,m).SBID indicates cases i), ii) or iii) above. In case i), the processes described herein enforce that, within each sandbox instantiation 8, there is only ever a single, valid data item data(kn,m) corresponding to a particular data identifier data(kn,m).ID. If a data item data(kn,m) belongs to the originating sandbox instantiation 8, it automatically supersedes a pre-existing data item data(k≠kn,m) in the results list (which must belong to the main instantiation 7 or an antecedent sandbox instantiation of the sequence). In case ii), a pre-existing data item data(k≠kn,m) in the results list and having a sandbox identifier data(k≠kn,m).SBID corresponding to an antecedent sandbox instantiation 8 of the sequence is superseded if the currently considered data item data(kn,m): ^ has a sandbox identifier data(kn,m).SBID corresponding to the query originating sandbox instantiation 8; or ^ has a sandbox identifier data(kn,m).SBID corresponding to any antecedent sandbox instantiation belonging to the sequence and which is a descendent of the antecedent sandbox instantiation corresponding to the a sandbox identifier data(k≠kn,m).SBID; In case iii), a pre-existing data item data(k≠kn,m) in the results list and having a sandbox identifier data(k≠kn,m).SBID corresponding to the main instantiation 7 is superseded if the currently considered data item data(kn,m): ^ has a sandbox identifier data(kn,m).SBID corresponding to the query originating sandbox instantiation 8; or ^ has a sandbox identifier data(kn,m).SBID corresponding to an antecedent sandbox instantiation of a sequence of one or more antecedent sandbox instantiations 8 via which the query originating sandbox instantiation 8 descends from the main instantiation 7. If the currently considered data item data(kn,m) does not supersede the pre-existing data item data(k≠kn,m) in the results list (step S56|No), then the next data item data(kn,m+1) (if any) is considered (steps S7 and S8). If the currently considered data item data(kn,m) supersedes the pre-existing data item data(k≠kn,m) in the results list (step S56|No), then the pre-existing data item data(k≠kn,m) is removed from the results list and replaced by the currently considered data item data(kn,m) (step S57). The next data item data(kn,m+1) (if any) is then considered (steps S7 and S8). Once all data items data(kn,m) have been considered (step S7|Yes), the next component COMP(n,mn) or version is considered (see step S9 in Figure 6) Write / modification request using data items Referring also to Figure 16, a process is illustrated for handling requests to write and / or modify record data record(kn,m) in the form of data items data(kn,m). The process shown in Figure 16 is carried out in an active instantiation, which may be the main instantiation 7 or any sandbox instantiation 8, in response to a request to write or modify record data record(kn,m) of a component COMP(n,mn) and corresponding to a given data identifier ID0. A new data item data(Kn,m) is added to component COMP(n,mn) to store the new or modified information (step S58). The new data item data(Kn,m) will also be the latest, so if there were Kodata items data(kn,m) previously, there will now be Kn,m= Ko+ 1 data items data(kn,m). When generating the new data item data(Ko+ 1 ): ^ The new or modified information is stored to the data payload data(Ko+ 1).PL; ^ The data identifier data(Ko+ 1).ID is set equal to the given data identifier, data(Ko+ 1).ID = ID0; ^ The sandbox identifier data(Ko+ 1 ).SBID is set to correspond to the active instantiation, for example denoting the active instantiation as SBIDact, data(Ko+ 1).SBID = SBIDact; and ^ The start time tstartis set equal to the time tmodof the write request, for example data(Ko+ 1).ValidRange = [tmod, ) in a case where the end time tendis left unset to denote ongoing validity. Alternatively, if ongoing validity is denoted by a predetermined value such as NaN (see Figure 14), data(Ko+ 1).ValidRange = [tmod, NaN). The new data item data(Ko+ 1) is always added, whether the given data identifier ID0is being added for the first time or is already present in a pre-existing data item data(kn,m<Ko+ 1).ID = ID0. Starting with the first data item data(1) in the component COMP(n,mn) (step S59), it is checked whether the component COMP(n,mn) includes a pre-existing data item data(kn,m<Ko+ 1) having a data identifier matching the new data item data(Ko+ 1) (step S60). In other words, whether data(kn,m<Ko+ 1).ID = ID0= data(Ko+ 1).ID. If the pre-existing data item data(kn,m<Ko+ 1) corresponding to a different data identifier (step S60|No), i.e. data(kn,m<Ko+ 1).ID ≠ ID0, then provided the next data item data(kn,m+1) is not the new data item data(Ko+ 1) (step S64|Yes), the next data item data(kn,m+1) is considered (step S65). If the pre-existing data item data(kn,m<Ko+ 1) has a data identifier matching the new data item data(Ko+ 1) (step S60|Yes), then is it considered whether the pre-existing data item data(kn,m<Ko+ 1) corresponds to the active instantiation (step S61). In other words, whether data(kn,m<Ko+ 1).SBID = SBIDact= data(Ko+ 1).SBID. When the active instantiation is the main instantiation 7, the corresponding sandbox identifier SBIDactmay be no data (null) or a predetermined value corresponding to the main instantiation 7 (for example, 0, -1 or NaN). If the pre-existing data item data(kn,m<Ko+ 1) does not correspond to the active instantiation (step S61|No), i.e. data(kn,m<Ko+ 1).SBID ≠ SBIDact, then provided the next data item data(kn,m+1) is not the new data item data(Ko+ 1) (step S64|Yes), the next data item data(kn,m+1) is considered (step S65). Whether this corresponds to the pre-existing data item data(kn,m<Ko+ 1) belonging to an antecedent instantiation of the active instantiation SBIDact, or to an entirely independent sandbox instantiation 8 is not relevant: the end time tendof the pre-existing data item data(kn,m<Ko+ 1) should not be set or modified, because the pre-existing data item data(kn,m<Ko+ 1) may remain valid and relevant in its own instantiation (main 7 or sandbox8 ) and / or descendants thereof. The pre-existing data item data(kn,m<Ko+ 1) will already be superseded by the new data item data(Ko+ 1) on the timeline of the active instantiation SBIDactin accordance with the processes explained hereinbefore (see in particular Figures 6 to 8 and 15). If the pre-existing data item data(kn,m<Ko+ 1) corresponds to the active instantiation (step S61|Yes), then it is checked whether the pre-existing data item data(kn,m<Ko+ 1) has an end time tenddenoting ongoing validity (step S62). For example: ^ In the case where the end time tendis left unset to denote ongoing validity, whether data(Ko+ 1).ValidRange = [tmod, ); or ^ In the case where ongoing validity is denoted by a predetermined value of tendsuch as NaN (see Figure 14), whether data(Ko+ 1).ValidRange = [tmod, NaN). The pre-existing data item data(kn,m<Ko+ 1) may have an end time tendindicating it is not valid (step S62|No), i.e. tend< tmod, in implementations in which deletion is indicated by removing a data item data(kn,m) from the timeline as discussed hereinbefore. Specifically, in the case that the corresponding object (for the given data identifier ID0) was previously deleted, but is now being re-inserted. When the pre-existing data item data(kn,m<Ko+ 1) has an end time tenddenoting ongoing validity (step S62|Yes), the end time tendof the corresponding validity range data(kn,m<Ko+ 1).ValidRange is set to the time of the write / modification (step S63), i.e. tend= tmod, and processing of the write / modify request is completed. There is no need to check for other pre-existing data items data(kn,m<Ko+ 1), as the rules and processes of the computing environment 6 prevent the existence of more than one valid pre-existing data item data(kn,m<Ko+ 1) corresponding to the active sandbox instantiation SBIDactand the given data identifier ID0. In this way, the pre-existing data item data(kn,m<Ko+ 1) is valid up to, but not including, the write / modification time tmod, and the new data item data(Ko+ 1) is valid from the write / modification time tmod onwards. Deletion requests when implemented by removal from the respective timeline Referring also to Figure 17, a method is illustrated for processing a request, within an active instantiation SBIDactto delete record data record(kn,m) corresponding to an object from a component COMP(n,mn), in the case that deletions are implemented by removal from the timeline of the active instantiation SBIDact. The deletion request concerns deletion of a specific data item data(kn,m). It should be noted that the data item data(kn,m) to be deleted must be one which belongs to the timeline of the active SBIDact, since otherwise a user could not see it to request deletion. It is first checked whether the sandbox identifier data(kn,m).SBID of the data item data(kn,m) to be deleted corresponds to the active instantiation (step S66), i.e. whether .SBID = SBIDact. If the data item data(kn,m) to be deleted belongs to the active instantiation SBIDact(step S66|Yes), then the end time tendof the data item data(kn,m) to be deleted is set equal to the time of the deletion request tdel, i.e. tend= tdel, data .ValidRange = [tstart, tdel). In this way, the now deleted data item data(kn,m) will not belong to the timeline of the active instantiation SBIDact after the deletion time tdel. However, if the data item data(kn,m) to be deleted is inherited from an antecedent instantiation (step S66|No), the data item data(kn,m) needs to be removed from the timeline of the active SBIDactwithout affecting validity of the data item data(kn,m) in other instantiations (main 7 or sandbox 8). If the sandbox identifier data(kn,m).SBID of the data item data(kn,m) to be deleted corresponds to an antecedent instantiation (main 7 or sandbox 8) of the active instantiation SBIDact(step S68|Yes), then a new data item is added to the corresponding component COMP(n,mn) (step S69). If the number Kn,mof data items data(kn,m) prior to the adding the new data item was K0, then denote the new data item as data(K0+1) and presume in the following discussion that the data item data(kn,m) to be deleted satisfies kn,m<Ko + 1. Generating the new data item data(K0+1) involves: ^ setting the data identifier data(K0+1).ID of the new data item to match the deleted data item, i.e. data(K0+1).ID = data(kn,m).ID; ^ setting the sandbox identifier data(K0+1).SBID of the new data item to correspond to the active sandbox instantiation, i.e. data(K0+1).SBID = SBIDact; ^ setting the start tstartand end tendtimes of the new data item equal to the time of the deletion request, i,e, data(K0+1).ValidRange = [tdel, tdel); and ^ setting the data payload data(K0+1).PL of the new data item: o to store nothing; or o to store the data payload of the deleted data item, i.e. data(K0+1).PL = data(kn,m).PL. In this way, the new data item data(K0+1) will supersede the data item data(kn,m) which is now deleted from the timeline of the active instantiation SBIDact, but remains unaffected from the perspective of any other instantiations. It should be noted that an outcome in which step S68 evaluates to “No” should not be possible, and is only included in Figure 17 for completeness and clarity. Deletion requests when implemented by deletion flags In the alternative case, deletions are handled by flagging data items data(kn,m) as deleted. This may be implemented by including a flag data(kn,m).Deleted to every data item, data(kn,m) storing a logical (true or false) value. Deleted data items are filtered out from read queries by including a filter requiring data(kn,m).Deleted = false. A request is received within an active instantiation SBIDactto delete a data item data(kn,m). The active instantiation SBIDactmay be the main instantiation 7 or a sandbox instantiation 8. At the time tdelof the request, the corresponding component COMP(n,mn) includes K0items, such that kn,m≤ K0. A new data item data(K0+1) is generated in active instantiation SBIDactby: ^ setting the data identifier data(K0+1).ID of the new data item equal to the data item data(kn,m) being deleted, i.e. data(K0+1).ID = data(kn,m).ID; ^ setting the sandbox identifier of the new data item data(K0+1).SBID to correspond to the active instantiation, i.e. data(K0+1).SBID = SBIDact; ^ setting the start time tstartof the new data item data(K0+1) equal to the time tdelof the deletion request and setting the end time tendto indicate ongoing validity, for example data(K0+1).ValidRange = [tdel, NaN); ^ setting the data payload data(K0+1).PL of the new data item: o to store nothing; or o to store the data payload of the data item being deleted, i.e. data(K0+1).PL = data(kn,m).PL. When the data item data(kn,m) being deleted from the active instantiation SBIDactbelongs to an antecedent instantiation 7,8 of the active instantiation SBIDact, the new data item data(K0+1) will automatically supersede the data item data(kn,m) on the timeline of the active instantiation SBIDactand is flagged as deleted. However, if the data item data(kn,m) being deleted belongs to the active instantiation, i.e. in the case when data(kn,m).SBID = SBIDact, it is also necessary to set the end time tendof the data item data(kn,m) equal to the time tdelof the deletion request, i.e. data(kn,m).ValidRange = [tstart, tdel). In this way, the data item data(kn,m) is valid on the timeline of the active instantiation SBIDactup to, but not including, the deletion time tdel, thereafter the timeline of the active instantiation SBIDactsees the new data item data(K0+1) which is flagged as deleted. For example, consider a first sandbox instantiation 8a with sandbox identifier SBID = 1 and a data item data(k0), where the corresponding component COMP(n,mn) included a number Kn,m= K0data items data(kn,m) at the start time of this example. Data item data(k0) is deleted from within the sandbox instantiation 8a at time tdelby generating a new data item data which is flagged as deleted, i.e. data(Ko+1).Deleted = true. Consider a first case in which a second sandbox instantiation 8b with sandbox identifier SBID = 2 is generated within the first sandbox instantiation 8a at a time tcreate> tdel. In this first case, the new data item data(Ko+1) is the valid item for the data identifier data(k0).ID= data(Ko+1).ID on the timeline of the second sandbox instantiation 8b, and is flagged as deleted. However, if in a second case the second sandbox instantiation 8b had been generated before the deletion, i.e. tcreate< tdel, then the valid item for the data identifier data(k0).ID= data(Ko+1).ID on the timeline of the second sandbox instantiation 8b, would be the data item data(k0), which is not flagged as deleted. Versioning components using data items Referring also to Figures 18A and 18B, an example is shown of change made to the structure of a data item data(kn,m) which results in generating a new version of the corresponding component COMP(n,mn). Figure 18A shows a component COMP(n,1) which exists in a single version, Mn= 1. The component COMP(n,1) stores a number Kn,mof data items data(kn,m) as described hereinbefore. In the example shown in Figure 18A, the data items data(kn,1) stored in component COMP(n,1) have data identifiers data(kn,1).ID which are separate from the data payload data(kn,m).PL, and the data payload data(kn,1).PL takes the form of a number F=F0(positive integer) of database fields field(f), with index 1 ≤ f ≤ F0. A user accessing an active instantiation SBIDactmay modify the structure of the data items data(kn,m), in the example shown in Figure 18 the modification is to insert a new field 20 in between the second field field(2) and the third field field(3). For example, referring again to Figure 14, consider if the IT department of the illustrated example decided to switch from dynamic to fixed IP addresses, and wanted to add a new column to the table of Figure 14 to store the fixed IP addresses. Any modification to the structure of the data items data(kn,m) (or more general record data record(kn,m)) should also be accompanied by compatibility information 21. Compatibility information 21 may be generated automatically by the computing environment 6, input by a user via client 11a, 11b, or a mixture of the two. The computing environment 6 distinguishes between two types of changes to the structuring of data leading to a new version of a component COMP(n,mn), also referred to as herein as a “migration”. Compatible migrations A compatible migration is one that does not require changes to existing data items data(kn,m). For example, referring again to the Figure 14 example, changing the name of the field, for example to instead by named “Office”, would be a compatible As another example, changing a field to a compatible type would be a compatible migration, as would adding a new field the completion of which was optional. For example, if the format of dates and times in the “ValidRange” column of the Figure 14 example was switched from day-month-year to the alternative month- day-year format – no new data is needed. This is also an example of a change to the data item data(kn,m) which is not made to the data payload data(kn,m).PL but to a parameter of the data item data(kn,m) itself. Compatible migrations may avoid the need to copy all the data items data(kn,m) of a component COMP(n,mn), and may for example be optimized by the computing environment 6. For example a second version COMP(n,2) may be defined by reference to the first version COMP(n,1), storing only the necessary differences such as optional fields, or an indication to change a display type of data. For example, if an optional field field(f0) is added at a version time tver. This means that no data item data(kn,m) has a value of this optional field field(f0) before tver. In this example, the original version, say COMP(n,1) may be regarded as a static view. This means that we have logically COMP(n,1) and COMP(n,2) as there was a structural change. However, in terms of how this is physically implemented, both versions COMP(n,1), COMP(n,2) share the same data items data(kn,m) up to the optional field field(f0). This is possible because in this example an optional field was added. The computing environment 6 may be configured so that sandbox instantiations 8 which see the old version COMP(n,1) do not return the new optional field field(f0), whilst queries within sandbox instantiations 8 which see the new version COMP(n,2) return data items data(kn,m) from the old version COMP(n,1), and additionally return the new optional field field(f0). In this way, it may not be necessary to copy all data items data(kn,m) when generating a new version COMP(n,2) for compatible migration. In other examples, it might be preferred to copy all the data items data(kn,m) from the old version COMP(n,1). Incompatible migrations Incompatible migrations are those that require special logic, or even initial values, in order to adapt the existing data items data(kn,m). Because of this, the computing environment 6 cannot optimize the migration, and must instead copy and adapt each affected data item data(kn,m) in order to keep the versions isolated. Taking the example hereinbefore of adding a new column of static IP addresses to the table of Figure 14, this would represent an incompatible migration, because at least the ongoing rows would need to be updated with an assigned value. This distinction into compatible and incompatible migrations facilitates an optimization by stacking versions whenever possible instead of executing physical data copies in every case, as it would be in, for example, a traditional database system. The compatibility information 21 includes information (whether manually entered or automatically generated) about the type of migration (compatible or incompatible). For an incompatible migration, the compatibility information 21 may also include the required logic and / or initial values for the change. In some implementations, the same sandbox instantiations 8 as are used for manipulating data items data(kn,m) may also be used for making changes to the structure of components COMP(n,mn), metadata 19 and / or data item data(kn,m) structures. Referring in particular to Figure 18B, the second version COMP(n,2) of the component COMP(n,1) of Figure 18A is shown. The data payload data(kn,2).PL of the data item data(kn,2) now includes a number F=F0+1 of database fields field(f), including the new field 20 inserted as field(3). Within the active instantiation SBIDact, queries after the time tverof the version update will see the new component COMP(n,2). Similarly, descendent sandbox instantiations created after the time tcreate> tverof the version update will also see the new component COMP(n,2). However, a descendent sandbox instantiations created before the time tcreate< tverof the version update will continue to see the previous version COMP(n,1), as will antecedent instantiations of the active instantiation SBIDact(as will sandbox instantiations 8 which are independent from the active instantiation SBIDact). A separate table within the computing environment may track which version mnof each component COMP(n,mn) is active for each time period and each instantiation (main 7 or sandbox 8). This may be conveniently implemented using a global component COMPglobal storing data items data(kn,m) having the component COMP(n,mn) version number mnas data payload PL, the component COMP(n,mn) number n as data identifier ID, then using the sandbox identifier SBID and ValidRange to track the validity of each component COMP(n,mn) version mnin relation to timelines of each instantiation 7, 8. Merging using data items Referring also to Figure 19 to 23, an example of the merging process shall be explained when record data record(kn,m) takes the form of data items data(kn,m). As described hereinbefore, the merge command identifies a sandbox instantiation 8 as the source instantiation and a target instantiation which may be the main instantiation 7 or any sandbox instantiation 8 which is not the source instantiation. In the following description the sandbox identifier SBID of the source instantiation shall be denoted SBIDsourceand the sandbox identifier SBID of the target instantiation shall be denoted SBIDtarget. When the target instantiation is the main instantiation 7, the sandbox identifier SBID of the target instantiation SBIDtargetmay be empty (or null), or may be set to a predetermined value corresponding to the main instantiation 7. A set of source data items SOURCE (alternatively a “first” set) is collated which includes all data items data(kn,m) belonging to the timeline of the source instantiation SBIDsource(step S70). In an implementation where deletions are implemented by excluding deleted data items data(kn,m) from timelines, the SOURCE set may be collated by, for example, executing a read query within the source instantiation SBIDsourcewithout filters in accordance with the method illustrated in Figure 15 and described hereinbefore. In an implementation where deletions are implemented by adding new, superseding data items data(K0+1) which are flagged as deleted, i.e. data(K0+1).Delete, the SOURCE set may be similarly collated by executing the read query with a filter to exclude deleted data items data(kn,m). In a case where the target instantiation SBIDtargetis the main instantiation (step S71|Yes), a set of target data items TARGET (alternatively a “second” set) is collated which includes data items data(kn,m) from the main instantiation which are valid up to a time of the merge tmerge(step S72). In this case, the TARGET set includes, for each component COMP(n,mn) (in particular the version valid in the main instantiation), all data items data(kn,m): ^ which have a sandbox identifier data(kn,m).SBID matching the main instantiation 7, for example data(kn,m).SBID = { } or data(kn,m).SBID = NaN); and ^ which have a validity range data(kn,m).ValidRange denoting validity at the merge time tmerge, for example data(kn,m).ValidRange = [tstart, { }) or data(kn,m).ValidRange = [tstart, NaN). Noting that the examples of empty entries { } / NaN are merely examples of SBID and tend values which can be chosen to represent respectively the main instantiation 7 and ongoing validity, and that other values could be used as described hereinbefore. Alternatively, in a case where the target instantiation SBIDtargetis the a different sandbox instantiation 8 to the source instantiation SBIDsource(step S71|No), the set of target data items TARGET is collated by including all data items data(kn,m) belonging to the timeline of the target instantiation SBIDtarget(step S73). In this case, the TARGET set may be compiled in the same way as the SOURCE set, except that read queries are executed within the target instantiation SBIDtarget. A merging set MERGE is formed by subtracting an intersection of the SOURCE set and the TARGET set from a union of the SOURCE set and the TARGET set (step S74). Referring in particular to Figure 20, the SOURCE and TARGET sets are schematically illustrated as a Venn diagram. The SOURCE set is illustrated on the left-hand side and the TARGET set on the right- hand side. The intersection, SOURCE ∩ TARGET corresponds to the data items data(kn,m) which are identical on both timelines. For example, if the source instantiation SBIDsourceis a descendent of the target instantiation SBIDtarget, then the intersection SOURCE ∩ TARGET corresponds to the data items data(kn,m) which have not been modified in the timeline of the source instantiation SBIDsourceor in the timeline of the target instantiation SBIDtargetsince the timeline of the source instantiation SBIDsourcediverged (or branched) from that of the target instantiation SBIDtarget. In an alternative example, that the source instantiation SBIDsourceand the target instantiation SBIDtargetmay be independent of one another but both depend from a common antecedent instantiation 7, 8 (at least the main instantiation 7). In this case, the intersection SOURCE ∩ TARGET corresponds to the data items data(kn,m) which have not been which have not been modified in the timeline of the source instantiation SBIDsourceor in the timeline of the target instantiation SBIDtargetsince those timelines diverged (or branched) from the common antecedent instantiation 7, 8. Herein, the condition for a first data item data(k1) to be equal to (or equivalently “identical” to) a second data item data(k2) is defined by: a) The first data(k1) and second data(k2) data items have identical data identifier ID, i.e. data(k1).ID = data(k2).ID; b) The first data(k1) and second data(k2) data items have identical sandbox identifier SBID, i.e. data(k1).SBID = data(k2).SBID; and c) The first data(k1) and second data(k2) data items have identical start times tstart. If these values are all identical, then other data of the first data(k1) and second data(k2) data items should also be identical, because this is enforced by the processes for reading, writing, modifying and deleting data items data(kn,m) described herein. Set operations such as unions, intersections and so forth carried out on sets of data items, such as the SOURCE and TARGET sets, use the preceding definition of equality as the condition for identity between a pair of data items data(k1), data(k2). There is no need (i.e. it would redundant) to check for quality of end times tend, data payload data(k1).PL, data(k2).PL and any other information stored in the data items data(k1), data(k2) such as global flags, deleted flags and so forth. Nonetheless, in some examples one, some or all of the data payloads data(k1).PL, data(k2).PL and other values may optionally be checked as well. Any discrepancies may indicate the presence of data corruption and / or tampering (since as explained there should be no deviations if the preceding conditions a) to c) are satisfied). Typically, the intersection SOURCE ∩ TARGET may be larger or significantly larger than the MERGE set. The MERGE set includes only those data items data(kn,m) which correspond to objects whose representation has diverged between the source SBIDsourceand target SBIDtarget instantiations. The intersection MERGE ∩ SOURCE, or equivalently SOURCE – (SOURCE ∩ TARGET), includes data items data(kn,m) which: ^ Were created (to correspond to new objects / data) in the source instantiation SBIDsourceor an antecedent sandbox instantiation 8 which is not a common antecedent with the target instantiation SBIDtarget; ^ Were most recently modified on the timeline of the source instantiation SBIDsourcewithin the source instantiation SBIDsourceor an antecedent sandbox instantiation 8 which is not a common antecedent with the target instantiation SBIDtarget; or ^ Have been deleted within the target instantiation SBIDtarget but not within in the source instantiation SBIDsource(whichever version of deletion is used) The intersection MERGE ∩ TARGET, or equivalently TARGET – (SOURCE ∩ TARGET), includes data items data(kn,m) which: ^ Were created (to correspond to new objects / data) in the target instantiation SBIDtargetor an antecedent sandbox instantiation 8 which is not a common antecedent with the source instantiation SBIDsource; ^ Were most recently modified on the timeline of the target instantiation SBIDtargetwithin the target instantiation SBIDtargetor an antecedent sandbox instantiation 8 which is not a common antecedent with the source instantiation SBIDsource; or ^ Have been deleted within the source instantiation SBIDsourcebut not within in the target instantiation SBIDtarget(whichever version of deletion is used) Referring again to Figure 19, after forming the merging set MERGE (step S74), there is optionally (though preferably) a conflict detection process (step S75), followed by implementing the merge by modifying record data record(kn,m), i.e. data items data(kn,m), of the target instantiation SBIDtargetbased on data items data(kn,m), belonging to the merging set MERGE (step S76). As described hereinbefore, the modification of the target instantiation SBIDtarget(step S76) may be conducted by simply overwriting data items data(kn,m) in the target instantiation SBIDtargetwith the data items data(kn,m) from the source instantiation SBIDsource. One example of a simple overwriting process starts by determining the intersection MERGE ∩ SOURCE. With the pthof a number P (positive integer) of data items belonging to the intersection MERGE ∩ SOURCE denoted data(p), in a first stage of the overwrite process, for each of p=1 to p=P, a new data item data(Kn,m+1) is generated in the component COMP(n,mn) corresponding to currently considered data item data(p) by (presuming Kn,m= K0prior to adding a new data item): ^ Copying the data payload PL of the currently considered data item data(p) to the new data item data(K0+1), i.e. data(p).PL = data(K0+1).PL; ^ Copying the data identifier ID of the currently considered data item data(p) to the new data item data(K0+1), i.e. data(p).ID = data(K0+1).ID; ^ Setting the sandbox identifier SBID of the new data item data(K0+1) to correspond to the target instantiation, i.e. data(K0+1).SBID = SBIDtarget; ^ Setting the start time tstartof the new data item data(K0+1) equal to the time of the merge tmerge, for example data(K0+1).ValidRange = [tmerge, NaN); and ^ In the case where the TARGET set includes a pre-existing data item data(kn,m) having a data identifier ID matching the currently considered data item data(p), i.e. data(p).ID = data(kn,m).ID, setting the end time of the pre-existing data item data(kn,m) equal to the time of the merge, i.e. data(kn,m).ValidRange = [tstart, tmerge). With the pthof a number P (positive integer) of data items belonging to the intersection MERGE ∩ TARGET denoted again as data(p), in a second stage of the overwrite process, for each of p=1 to p=P, it is determined whether a component COMP(n,mn) corresponding to the currently considered data item data(p) includes one or more deleted data items data(kn,m): ^ Which have a sandbox identifier data(kn,m).SBID corresponding to the source sandbox instantiation SBIDsourceor an antecedent instantiation of the source sandbox instantiation SBIDsource; and ^ Which have a data identifier data(kn,m).ID: o that matches the currently considered data item data(p), i.e. data(kn,m).ID = data(p).ID; and o that does not match any data item from the SOURCE set; In response to a positive determination of one or more deleted data items data(kn,m), the end time of the currently considered data item data(p) is set equal to the time of the merge tmerge. In other words, if the target instantiation SBIDtargetincludes a data item data(kn,m) corresponding to an object which is deleted from the source instantiation SBIDsource, that data item data(kn,m) is deleted from the target instantiation SBIDtarget. In the second stage of the overwrite process, all data items data(kn,m) of the component COMP(n,mn) corresponding to the currently considered data item data(p) need to be considered, rather than simply checking the TARGET set, because deleted data items will have been excluded from the timeline (either innately or by filtering out data items data(kn,m) flagged as deleted, i.e data(kn,m).Delete = true). As illustrated in Figure 19, the merging set MERGE is collated in full after receiving the command to merge the source sandbox instantiation SBIDsourceinto the target instantiation SBIDtarget, and before starting to generate implement the merge. Alternatively, each data item data(kn,m) of each component COMP(n,mn) may be considered in turn, with membership of the merging set MERGE being determined in real-time (sometimes alternatively termed “on-the-fly”). Especially if a conflict detection process (step S75) is being implemented, it is preferable to collate the merging set MERGE in full before starting to modify the target instantiation SBIDtarget. Conflict detection using data items Although a merging process may be conducted using the overwriting method described hereinbefore, the benefits of the computing environment 6 may be more fully obtained when a conflict detection process is implemented. The conflict detection process (step S75) is similar to the process described in relation to Figures 10 and 11. For example, referring in particular to Figures 21 to 23, an example of a conflict detection process is described for a computing environment 6 in which record data record(kn,m) is stored in the form of the data items data(kn,m). Starting with the first component n = 1 (step S77) and version mn= 1 (step S78) COMP(1,1), and subsequently for each component (steps S84 and S85) and version thereof (steps S82 and S83): ^ All data items data(kn,m) belonging the mnthversion of the nthcomponent COMP(n,mn) which also belong to the intersection of the MERGE and SOURCE sets are processed to flag conflicts in a first conflict-check stream (step S79); and ^ All data items data(kn,m) belonging the mnthversion of the nthcomponent COMP(n,mn) which also belong to the intersection of the MERGE and TARGET sets are processed to flag conflicts in a second conflict-check stream (step S80). Depending on the number and type of computer system(s) 9 and processor(s) 13 included in the computing environment 6, the first (step S79) and second (step S80) conflict-check streams may be executed in parallel or in sequence. Each conflict-check stream may be further parallelised for more efficient processing. An example of the first conflict-check stream (step S79) is shown in Figure 22 and described in further detail hereinafter. An example of the second conflict-check stream (step S80) is shown in Figure 23 and described in further detail hereinafter. Once all conflicts have been flagged, actions for resolving each flagged conflict are selected (step S81). In the same way as described hereinbefore, for each data item data(kn,m) flagged for conflict resolution (in steps S79 or S80), that conflict may be processed according to pre-set rules, or a user may be prompted (via client 11a, 11b) to provide input determining how to process the conflict. As described hereinbefore, in implementations where a user supplies conflict resolution instructions via a client 11a, 11b, the computing system 6 may determine all conflicts and require input to resolve each before proceeding with the merge. Alternatively, the computing system 6 may start executing the merge, and prompt user input for conflict resolution when a conflict is detected. Actions for resolving a conflict flagged between a first data item data(k1) from the source instantiation SBIDsourceand a second data item data(k2) from the target instantiation SBIDtargetmay include, without being limited to (presuming Kn,m= K0prior to adding a new data item): ^ replacing the second data item data(k2) in the target instantiation by generating a new data item data(K0+1) in the target instantiation SBIDtargetvalid from the merge term (tstart= tmerge) and copying across the data payload of the first data item data(k1).PL, and in addition setting an end time tendof the second data item data(k2) equal to the time of the merge tmerge, i.e. data(k2).ValidRange = [tstart, tmerge); ^ Deleting the second data item data(k2). Depending on how deletions have been implemented, by setting an end time tendof the second data item data(k2) equal to the time of the merge tmerge, i.e. data(k2).ValidRange = [tstart, tmerge), or by setting the deletion flag data(k2).Delete = true; ^ Generating a new data item data(K0+1) in the target instantiation SBIDtargetvalid from the merge term (tstart= tmerge) and having data payload data(K0+1).PL based on both the data payloads of the first data(k1).PL and second data(k2).PL data items; ^ Generating a new data item data(K0+1) in the target instantiation SBIDtargetvalid from the merge term (tstart= tmerge) and having data payload data(K0+1).PL based on user input received via client 11a, 11b in response to a prompt. Once all flagged conflicts have had a corresponding action selected (step S81), the conflict detection is repeated for each version mnof each component COMP(n,mn) (steps S82 to S85), it is checked whether the set of actions determined through steps S79 to S81 will violate any rules or constraints set for one or more components COMP(n,mn) of the computing system 6 more broadly (step S86). This is the same as described previously in relation to the processed illustrated in Figure 10 (see step S44). The process then proceeds to implement all the selected actions to carry out the merge (step S76). First conflict-detection stream Referring in particular to Figure 22, an example of the first conflict-check steam (step S79) is shown. In the description of the example of the first conflict-check steam (step S79) illustrated in Figure 22, P (positive integer) is used to denote the number of data items data(kn,m) belonging the mnthversion of the nthcomponent COMP(n,mn) which also belong to the intersection of the MERGE and SOURCE sets. The pthof P such data items is denoted data(p). Starting with the first, p = 1 (step S87), it is determined (step S88) whether the component COMP(n,mn) corresponding to the currently considered data item data(p) includes one or more pre-existing data items data(kn,m): ^ which have a data identifier data(kn,m).ID matching the currently considered data item data(p).ID; and ^ which have a sandbox identifier data(kn,m).SBID corresponding to the target instantiation SBIDtargetor an antecedent instantiation of the target instantiation SBIDtarget. A negative determination (step S88|No) corresponds to the situation that the currently considered data item data(p) corresponds to an object which has never existed before in the timeline of the target instantiation SBIDtarget(even including deleted data items data(kn,m). Such a data item data(p) is flagged for addition to the target instantiation (step S89). Being flagged for addition to the target instantiation SBIDtarget(step S89) means that subsequently, when the merge is implemented (step S76), a new data item data(Kn,m+1) will be generated within the component COMP(n,mn) corresponding to the flagged data item data(p) by (presuming Kn,m= K0prior to adding a new data item): ^ copying the data payload PL of the flagged data item data(p) to the new data item data(K0+1), i.e. data(K0+1). PL = data(p).PL; ^ copying the data identifier ID of the flagged data item data(p) to the new data item data(K0+1), i.e. data(K0+1). ID = data(p).ID; ^ setting the sandbox identifier SBID of the new data item data(K0+1)to correspond to the target instantiation, i.e. data(K0+1).SBID = SBIDtarget; ^ setting the start time tstartof the new data item data(K0+1) equal to the time of the merge tmerge, for example data(K0+1).ValidRange = [tmerge, NaN); and ^ optionally when flags such as data(kn,m).Global or similar are used, any such flags should also be set at the time of adding the data item data(K0+1). If one or more pre-existing data items data(kn,m) are found at step S88, it is checked whether the TARGET set includes any data data(kn,m) which have a data identifier data(kn,m).ID matching the considered data item data(p).ID (step S90). A negative determination (step S90|No) means that the object corresponding to the one or more pre-existing data items data(kn,m) found at step S88 has been deleted from the target instantiation SBIDtarget. In this case, the currently considered data item data(p) is flagged as a conflict (step S91), for subsequent selection of an action to resolve (step S81). For example, to decide whether the flagged data item data(p) be copied over to the target instantiation SBIDtarget, or whether it be left so that the object corresponding to that data identifier data(p).ID remains deleted in the target instantiation SBIDtarget. If the TARGET set does include a pre-existing data item data(kn,m) having the same data identifier ID as the currently considered data item data(p) (step S90|Yes), it is determined whether the component COMP(n,mn) corresponding to the currently considered data item data(p) includes a common antecedent data item (step S92), which shall be denoted data(ko) in the discussion hereinafter. A common antecedent data item data(k0): ^ has a data identifier ID matching the currently considered data item data(p), i.e. data(ko).ID = data(p).ID; and ^ has a sandbox identifier data(ko).SBID corresponding to an instantiation: o which is an antecedent of the source sandbox instantiation; and o is the target instantiation or is an antecedent thereof. If there is no common antecedent data item data(k0) (step S92|No), then the currently considered data item data(p) is flagged as a conflict (step S91), for subsequent selection of an action to resolve (step S81). For example, this combination of conditions could indicate that an object having the same data identifier ID has been independent added to wholly independent timelines, or that data has been corrupted or tampered with. In any case, prompting the user to check the flagged data item data(p) will prevent issues and / or errors being introduced to the target instantiation SBIDtarget, of particular importance if the target instantiation SBIDtargetis the main instantiation 7. In the case where a common antecedent data item data(k0) is found (step S92|Yes), it is checked whether the data payload data(k0).PL of the common antecedent data item data(k0) has changed on the timeline of the target instantiation SBIDtarget(step S93). This test may be evaluated by comparing the data payload data(k0).PL of the common antecedent data item data(k0) with the data payload data(kn,m).PL of the pre-existing data item data(kn,m) found in the TARGET set (at step S90). In the case that the data payload data(k0).PL of the common antecedent data item data(k0) is not the same as the data payload data(kn,m).PL of the pre-existing data item data(kn,m) found in the TARGET set (step S93|Yes), then the common antecedent data item data(k0) has been modified on the timeline of the target instantiation SBIDtarget, and it should preferably be considered whether such changes should be overwritten by the currently considered data item data(p), or retained in the target instantiation SBIDtarget. Therefore, the currently considered data item data(p) is flagged as a conflict (step S91), for subsequent selection of an action to resolve (step S81). For example, to determine (whether using pre-set rules or user input) whether to (presuming Kn,m= K0prior to adding a new data item): ^ Overwrite the pre-existing data item data(kn,m) found in the TARGET set by adding a new data item data(K0+1) within the target instantiation SBIDtarget, valid from time tmerge and copying the data payload data(p).PL of the flagged data item data(p); ^ Keep the pre-existing data item data(kn,m) found in the TARGET set without modification; ^ Add a new data item data(K0+1) within the target instantiation SBIDtarget, valid from time tmergeand having data payload data(p).PL based on combining data payload PL of the flagged data item data(p) with the pre-existing data item data(kn,m) found in the TARGET set; or ^ Add a new data item data(K0+1) within the target instantiation SBIDtarget, valid from time tmergeand having data payload data(p).PL based on user input received (via client 11a, 11b) in response to a prompt generated in response to flagging the data item data(p) as a conflict. In the case that the data payload data(k0).PL of the common antecedent data item data(k0) is the same as the data payload data(kn,m).PL of the pre-existing data item data(kn,m) found in the TARGET set (step S93|No), then the common antecedent data item data(k0) has not been modified on the timeline of the target instantiation SBIDtarget. In other words, the pre-existing data item data(kn,m) found in the TARGET set (at step S90) is the common antecedent data item data , and this has not been modified since the timeline of the source instantiation diverged from the timeline of the target instantiation SBIDtarget. In this case, the currently considered data item data(p) is flagged to replace the pre-existing data item data(kn,m) in the target instantiation SBIDtarget(step S94). Being flagged to replace the pre-existing data item data(kn,m) in the target instantiation SBIDtarget(step S94) means that subsequently, when the merge is implemented (step S76), presuming Kn,m= K0prior to adding a new data item, a new data item data(K0+1) will be generated within the component COMP(n,mn) corresponding to the flagged data item data(p) by: ^ copying the data payload PL of the flagged data item data(p) to the new data item data(K0+1), i.e. data(K0+1). PL = data(p).PL; ^ copying the data identifier ID of the flagged data item data(p) to the new data item data(K0+1), i.e. data(K0+1). ID = data(p).ID; ^ setting the sandbox identifier SBID of the new data item data(K0+1)to correspond to the target instantiation, i.e. data(K0+1).SBID = SBIDtarget; ^ setting the start time tstartof the new data item data(K0+1) equal to the time of the merge tmerge, for example data(K0+1).ValidRange = [tmerge, NaN); ^ In the case that the sandbox identifier SBID of the pre-existing data item data(kn,m) found in the TARGET set corresponds to the target instantiation, i.e. data(kn,m).SBID = SBIDtarget, the end time tendof that pre-existing data item data(kn,m) is set equal to the time of the merge tmerge, i.e. data(kn,m).ValidRange = [tstart, tmerge); and ^ optionally when flags such as data(kn,m).Global or similar are used, any such flags should also be copied across from the flagged data item data(p). Flagging a data item data(p) for conflict resolution may include, or take the form of, adding that data item data(p) to a list. If the conflict is with a pre-existing data item data(kn,m) from the TARGET set, the list may also include the pre-existing data item. Data items data(p) flagged for addition and / or replacement may be handled using separate lists. Alternatively, conflicts, additions and replacements may all be kept in a single list including for each an indication of the modification type. The indication of the modification type for each conflict is then filled in as described hereinbefore (at step S81). In the preceding explanation, data items data(p) are flagged for addition, to replace data in the target instantiation, for conflict resolution, as a batch before any modification is made. In other examples, each data item data(p) could instead be fully resolved before moving to the next. For example, a conflict could be detected, and instead of being flagged (step S91), a resolution action could be immediately selected (similar to step S81) and then implemented instead of waiting and batch processing modifications (see step 76). Second conflict-detection stream Referring in particular to Figure 23, an example of the second conflict-check steam (step S80) is shown. In the description of the example of the second conflict-check stream (step S80) illustrated in Figure 23, P (positive integer) is used to denote the number of data items data(kn,m) belonging the mnthversion of the nthcomponent COMP(n,mn) which also belong to the intersection of the MERGE and TARGET sets. The pthof P such data items is denoted data(p). Starting with the first, p = 1 (step S97), it is determined (step S98) whether the component COMP(n,mn) corresponding to the currently considered data item data(p) includes one or more pre-existing data items data(kn,m): ^ which have a data identifier data(kn,m).ID matching the currently considered data item data(p).ID; and ^ which have a sandbox identifier data(kn,m).SBID corresponding to the source instantiation SBIDsourceor an antecedent instantiation of the source instantiation SBIDsource. If any pre-existing data items data(kn,m) are found (step S98|Yes), then it is further checked whether one such pre-existing data items data(kn,m) belongs to the SOURCE set (step S99). If no pre-existing data items data(kn,m) are found (step S98|No), then the object corresponding to the currently considered data item data(p) never existed on the timeline of the source instantiation SBIDsource. No action is needed, and the next data item data(p+1) (if any) is considered (step S104 and S105). Similarly, if pre-existing data items data(kn,m) were found (step S98|Yes) but one such data item data(kn,m) belongs to the SOURCE set (step S99|Yes), then the object corresponding to that data identifier data(p).ID will be handled by the first conflict- detection stream described hereinbefore in relation to Figure 22. However, if pre-existing data items data(kn,m) were found (step S98|Yes) but none belong to the SOURCE set (step S99|No), then the corresponding object existed on the timeline of the source instantiation SBIDsource, but has been deleted at some time prior to the merge command at time tmerge. It should be checked whether or not the currently considered data item data(p) may be deleted in the target instantiation SBIDtargetwithout generating a conflict. It is determined whether the component COMP(n,mn) corresponding to the currently considered data item data(p) includes a common antecedent data item (step S100), which shall be denoted data(ko) in the discussion hereinafter. A common antecedent data item data(k0): ^ has a data identifier ID matching the currently considered data item data(p), i.e. data(ko).ID = data(p).ID; and ^ has a sandbox identifier data(ko).SBID corresponding to an instantiation: o which is an antecedent of the source sandbox instantiation SBIDsource; and o is the target instantiation or is an antecedent thereof. If there is no common antecedent data item data(k0) (step S100|No), then the currently considered data item data(p) is flagged as a conflict (step S101), for subsequent selection of an action to resolve (step S81). For example, this combination of conditions could indicate that an object having the same data identifier ID has been independent added to wholly independent timelines, or that data has been corrupted or tampered with. In the case where a common antecedent data item data(k0) is found (step S100|Yes), it is checked whether the data payload data(k0).PL of the common antecedent data item data(k0) has changed on the timeline of the target instantiation SBIDtarget(step S102). This test may be evaluated by comparing the data payload data(k0).PL of the common antecedent data item data(k0) with the data payload data(p).PL of the currently considered data item data(p). In the case that that data payload data(p).PL of the currently considered data item data(p) is different from the data payload data(k0).PL of the common antecedent data item data(k0) (step S102|Yes), then the common antecedent data item data(k0) has been modified on the timeline of the target instantiation SBIDtarget, and it should preferably be considered whether such changes should be overwritten by deleting the currently considered data item data(p) for consistency with the source instantiation SBIDsource, or whether the changes should be retained in the target instantiation SBIDtarget. Therefore, the currently considered data item data(p) is flagged as a conflict (step S101), for subsequent selection of an action to resolve (step S81). For example, to determine (whether using pre-set rules or user input) whether to (presuming Kn,m= K0prior to adding a new data item): ^ Keep the flagged data item data(p) without modification; ^ Delete the flagged data item data(p) for consistency with the source instantiation SBIDsource; or ^ Add a new data item data(K0+1) within the target instantiation SBIDtarget, valid from time tmergeand having data payload data(K0+1).PL based on user input received (via client 11a, 11b) in response to a prompt generated in response to flagging the data item data(p) as a conflict. In the case that the data payload data(k0).PL of the common antecedent data item data(k0) is the same as the data payload data(p).PL of the currently considered data item data(p) (step S102|No), then the common antecedent data item data(k0) has not been modified on the timeline of the target instantiation SBIDtarget. In other words, the currently considered data item data(p) is the common antecedent data item data(k0), and this has not been modified since the timeline of the source instantiation SBIDsourcediverged from the timeline of the target instantiation SBIDtarget. In this case, the currently considered data item data(p) is flagged for deletion in the target instantiation SBIDtarget(step S103). Being flagged for deletion in the target instantiation SBIDtarget(step S94) means that subsequently, when the merge is implemented (step S76), the flagged data item data(p) will be deleted, either by setting the tendvalue to the merge time tmerge, or by adding a new, superseding data item data(K0+1) which is flagged as deleted by setting the deletion flag data(K0+1).Delete, depending on how deletions are implemented in the computing environment. Flagging a data item data(p) for conflict resolution or for deletion may be handled in the same described in relation to flagging data items data(p) in relation to the first conflict-detection stream (see Figure 22). In the preceding explanation, data items data(p) are flagged for deletion or conflict resolution as a batch before any modification is made. In other examples, each data item data(p) could instead be fully resolved before moving to the next. For example, a conflict could be detected, and instead of being flagged (step S91), a resolution action could be immediately selected (similar to step S81) and then implemented instead of waiting and batch processing modifications (see step 76). Three-table format of record data Referring also to Figure 24, a further example structure for record data record(kn,m) is shown. In the example shown in Figure 24, the data items data(kn,m) belonging to each component COMP(n,mn) (or version thereof) are grouped into three separate tables. A main table 22 includes all the data items data(kn,m) which belong to the main instantiation 7 and which are valid at the present time. For brevity in the description hereinafter, data items data(kn,m) in the main table 22 shall be referred to as main data items main(kn,m), but otherwise use the same nomenclature as data items data(kn,m) described herein. Optionally, but not essentially, the sandbox identifier SBID may be completely omitted from main data items main(kn,m). The main table 22 may only ever have a single main data item main(kn,m) for each unique data identifier ID. A history table 23 includes all the data items data(kn,m) which belong to the main instantiation 7 and which have an end time tendbefore the present time. For brevity in the description hereinafter, data items data(kn,m) in the history table 23 shall be referred to as history data items hist(kn,m), but otherwise use the same nomenclature as data items data(kn,m) described herein. Optionally, but not essentially, the sandbox identifier SBID may be completely omitted from history data items hist(kn,m). It should be noted that whilst a history data item hist(kn,m) is not valid in the main instantiation 7, it may (and often will be) valid in one or more sandbox instantiation 7 which diverged from the main instantiation 7 before that history data item hist(kn,m) was superseded in the main instantiation 7 (and moved out of the main table 22). The history table 23 may contain multiple history data items hist(kn,m) having the same data identifier ID. A shadow table 24 includes all the data items data(kn,m) which belong to sandbox instantiations 7. For brevity in the description hereinafter, data items data(kn,m) in the shadow table 24 shall be referred to as shadow data items shad(kn,m), but otherwise use the same nomenclature as data items data(kn,m) described herein. The shadow data items shad(kn,m) within a given component may be valid in some sandbox instantiations 7, whilst being no longer valid (for example superseded of excluded from the timeline) in other sandbox instantiations 7, and / or irrelevant to still other sandbox instantiations 7. The indices kn,mfor main data items main(kn,m), history data items hist(kn,m) and shadow data items shad(kn,m) are independent, and each runs from 1 to the respective total numbermainKn,m,histKn,m,shadKn,m. Each total numbermainKn,m,histKn,m,shadKn,mis not fixed, it is simply the range of the index kn,mat a time of In the case that deletions are handled by setting the corresponding end time tendto exclude a deleted data item data(kn,m) from the timeline, deleted data items data(kn,m) which belong to the main instantiation 7 will be stored in the history table 23. In the case that deletions are handled using deletion flags, deleted data items data(kn,m) which belong to the main instantiation 7 will be stored in the main table 22 and flagged as deleted, i.e. main(kn,m).Delete = true. An advantage of the three table 22, 23, 24 format for record data record(kn,m) is that the logic of the operations of reading, writing and deleting record data record(kn,m), and for merging sandbox instantiation 8, may be simplified. Although the same tests and checks will need to be applied to shadow data items shad(kn,m) as were described hereinbefore in relation to data items data(kn,m), the checks may be greatly simplified in relation to main instantiation 7 data – the timeline of the main instantiation 7 is effectively just the main table 22. Given that the shadow table 24 only needs to hold data modified relative to the main instantiation 7 and / or other sandbox instantiations, in most computing environments 6 the majority of data will belong to the main instantiation 7. Consequently, a reduction in the complexity of logic needed to process data belonging to the main instantiation 7 may provide a significant optimisation of the speed of the computing environment 6 and / or the computing resources required. Worked example of three-table record data Referring also to Figures 25A to 25C, the three table structure explained in relation to Figure 24 is applied to the worked example shown in Figure 14. Figure 25A shows the main table 22 for the worked example shown in Figure 14, with sandbox identifiers SBID omitted from main data items main(kn,m) and with deletions implemented by setting the end time tend of a deleted item to exclude it from validity. Figure 25B shows the history table 23 for the worked example shown in Figure 14, with sandbox identifiers SBID omitted from main data items main(kn,m) and with deletions implemented by setting the end time tendof a deleted item to exclude it from validity. Figure 25C shows the shadow table 24 for the worked example shown in Figure 14, with deletions implemented by setting the end time tend of a deleted item to exclude it from validity. The optimisation of operations within the computing environment 6 using the three- table 22, 23, 24 structure explained in relation to Figures 24 to 25C may be most easily understood by relating it to the previously described operations. Read operation in the three-table case Referring also to Figure 26, a process for evaluating a read query within a sandbox instantiation 8 is shown. The evaluation of a read query within the main instantiation 7 is particularly simple, and involves simply applying any filters defined in the read query to the main table 22. Within an originating sandbox instantiation 8, the read query is handled as described hereinbefore, except for the logic for collating the results list for each component COMP(n,mn). The specific process is what is shown in Figure 26 (and the same process is repeated for each component COMP(n,mn) or version thereof which is covered by the read query). The shadow data items shad(kn,m) in the shadow table 24 for the component COMP(n,mn) are first filtered to retain only those which match the read query (step S106). The set of shadow data items shad(kn,m) matching the read query is then filtered to retain, for each unique data identifier ID, the most recent shadow data items shad(kn,m) from the timeline of the originating sandbox instantiation 8 (step S107), to determine a SANDBOX set of shadow data items shad(kn,m). The determination of whether a shadow data item shad(kn,m) belongs to the timeline of the originating sandbox instantiation 8 is substantially the same as described hereinbefore in relation to the data items data(kn,m). The main data items main(kn,m) in the main table 22 are for the component COMP(n,mn) are first filtered to retain only those which match the read query (step S106), then filtered again to retain only the main data items main(kn,m) from the timeline of the originating sandbox instantiation 8 (step S107). This is accomplished by comparing the validity periods of the main data items main(kn,m).ValidRange to the earliest creation time of the originating sandbox instantiation 8 or the sequence of one or more antecedent sandbox instantiations via which the originating sandbox instantiation 8 descends from the main instantiation 7. The history data items hist(kn,m) in the history table 23 are filtered identically to the main data items main(kn,m). A union of the filtered set of main data items main(kn,m) and the filtered set of history data items hist(kn,m) is obtained (step S108), then further filtered to remove any main data items main(kn,m) or history data items hist(kn,m) which share a data identifier with a shadow data item shad(kn,m) in the SANDBOX set (step S109), to determine a MAIN set. The results list for output is obtained as the union of the SANDBOX set and the MAIN set (step S110). The division of data items data(kn,m) into main 22, history 23 and shadow 24 tables may reduce the complexity of determining and returning data items which match the read query and belong to the timeline of the originating sandbox instantiation 8. This approach also lends itself to parallelisation processing the read query. Reducing the complexity necessary to accomplish the read query reduces computational cost and hardware requirements to operate the computing environment 6. Reducing computational cost also reduces power requirements (both for processors and heat extraction). The complexity of processing the read query may be further reduced, whether in the three-table 22, 23, 24 structured example or the preceding examples, by using deletion flags, for example main(kn,m).Delete, hist(kn,m).Delete and shad(kn,m).Delete to implement items having compared to performing potentially multiple tests of the respective validity ranges main(kn,m).ValidRange, hist(kn,m).ValidRange and shad(kn,m).ValidRange. A read query may be further optimised, whether in the three-table 22, 23, 24 structured example or the preceding examples, by maintaining a validity flag IsCurrent for all data items data(kn,m), or in the three-table structured case, the shadow data items shad(kn,m). The validity flags data(kn,m).IsCurrent are set to true for the most recent data item data(kn,m) corresponding to each unique combination of data identifier ID and sandbox identifier SBID. In this way, even when there are multiple data items data(kn,m) belonging to a single sandbox, the validity flags data(kn,m).IsCurrent may be used to efficiently identify which is currently valid in each sandbox instantiation 8. When used, the validity flags data(kn,m).IsCurrent are maintained by updating them in parallel with any or all of the operations or processes described herein in relation to writing, replacing, generating, deleting or otherwise processing data items data(kn,m) of one or more components COMP(n,mn), maintaining the invariant that IsCurrent is only set to true on the most recent data item data(kn,m) for each unique combination of data identifier ID and sandbox identifier SBID. For example, when during a process described herein the end time tend of a data item data(kn,m) is being set to, for example, a merge time tmerge, a write time tmodand so forth, because it is being superseded, the validity flag data(kn,m).IsCurrent of that data item data(kn,m) would be set to false at the same time. Write / modify requests in the three table structured case The processing of a write / modification request using the main 22, history 23 and shadow 24 tables is substantially the same as explained hereinbefore in relation to Figure 16. One difference is that entirely new data is only written to the main table 22 or the shadow table 24. Another difference is that that when a main data item main(kn,m) becomes superseded within the main instantiation 7, it is copied to a history data item hist(kn,m) and removed from the main table 22 (the order of these operations is not important). In accordance with the processes described hereinbefore, when a main data item main(kn,m) becomes superseded within a sandbox instantiation 8, that main data item main(kn,m) is not changed, and a superseding shadow data item shad(K0+1) is added to the shadow table, corresponding to the active sandbox instantiation 8. Deletion requests in the three table structured case The processing of a deletion request using the main 22, history 23 and shadow 24 tables is substantially the same as explained hereinbefore in relation to Figure 17. One difference is that in an implementation where end times tendare set to exclude a deleted item from the relevant timeline, a main data item main(kn,m) which is deleted will be copied to a history data item hist(kn,m), and removed from the main table 22 (the order of these operations is not important). Merge requests in the three table structured case The processing of a deletion request using the main 22, history 23 and shadow 24 tables is substantially the same as explained hereinbefore in relation to Figures 19 to 23. One difference is that the optimised processing of read queries in the three table structured implementation case will also be applicable to the initial stages of a merge operation, when collating the SOURCE and TARGET sets. Updating software in a sandbox instantiation Referring also to Figure 27A, a conventional software application upgrading process is illustrated. Traditionally, upgrading an application 26 results in a new system state, transitioning from the old version to the new version. In the example shown in Figure 27A, a server 25 is executing version X of an application 26 at a first time t1. Between the first time t1and a second time t2, the application 26 is upgraded to version X+1 of the application 26b. Upgrades come with inherent risks, including the introduction of bugs and problems. Therefore, testing upgrades before installation is crucial. However, in the traditional model of upgrading, the server 25 is only ever executing the version X application 26 or the version X+1 application 26b. This model has well known issues, in particular the stability and compatibility of the server 25 running the version X+1 application cannot be tested until after the upgrade. If there are issues which prevent the server 25 from running correctly when executing the version X+1 application 26b, this may result in significant downtime of the server 25 whilst the system is reverted to the version X application 26. Another approach involves creating an entirely separate test system, but this can lead to inaccuracies and other problems with outdated record data record(kn,m), data(kn,m) comparable to a conventional sandbox computing environment 3. The problems of conventional software application upgrading process may be mitigated using sandbox instantiations. Referring also to Figure 27B, a software application upgrading process using a sandbox instantiation is illustrated. The computing environment 6 addresses these challenges by allowing the coexistence of two versions of an application on a single system, for example the version X application 26 and the version X+1 application 26b, both able to see up-to-date record date record(kn,m), data(kn,m) to facilitate thorough testing of upgrades without affecting the main instantiation 7. Subject to any applicable user access controls, a user of the computing environment 6 accessing a sandbox instantiation 8 via client 11a, 11b may be permitted to install or update all or part of a software application 26 which is executable within the active sandbox instantiation 8. In the example shown in Figure 27B, between a first time t1 which is analogous to the starting point of Figure 27A and a second time t2, the version X+1 application 26b is installed in the sandbox instantiation. The installation or updating a software application 26 executable within an active sandbox instantiation 8 of the computing environment 6 may include, or take the form of, replacing any or all files etc corresponding to that application 26 within a component COMP(n,mn) storing that application. For example, a data item data(kn,m) may have a data payload data(kn,m).PL corresponding to executable computer code the application 26, and the data identifier data(kn,m).ID may be a file location (in a system being used within the computing environment 6). Other data items data(kn,m) associated with the application 26 may store libraries, configuration files, data repositories used by the application, and so forth. All data items data(kn,m) corresponding to the application 26 may belong to a single component COMP(n,mn), but it is equally possible that data items data(kn,m) corresponding to the application 26 could be distributed across two or more components COMP(n,mn). Data items data(kn,m) may be common to two or more applications 26, for example, a shared library or other resource useable by two or more applications 26, or between different versions X, X+1 of the same application 26, 26b running in different instantiations 7, 8 of the computing environment 6. The stability and compatibility of the version X+1 application 26b may be tested in the independent runtime of the sandbox instantiation 8. Any issues or problems will not affect the normal operation of the server 25 which can continue to execute the version X application 26. Any issues can be worked on and resolved within the sandbox instantiation 8 and / or descendent sandbox instantiations, before merging with the main instantiation 7. After the version X+1 application 26b applications 26b is installed in the sandbox instantiation 8, users can choose to use either the old (version X) or the new (version X+1) version of the application 26, 26b, while working with the same record(kn,m), data(kn,m). Actively selecting the sandbox instantiation 8 may be necessary to access the new version X+1 application 26b; the default behaviour may remain unchanged. Between the second time t2and third time t3, once testing is completed, any problems have been resolved withing the sandbox instantiation 8, and once users accept the upgrade, the sandbox instantiation 8 may be merged with the main instantiation 7 to apply the upgraded version X+1 application to the main instantiation for execution by the server 25. In this way, the computing environment 6 may realise several advantages when software 26 upgrades 26b are implemented using sandbox instantiations 8. Advantages include thorough testing, because new versions, for example version X+1 of application 26b, can be tested extensively without risking the degradation of features or the introduction of bugs within the main instantiation 7. Another advantage is integrity of the data record(kn,m), data(kn,m) of the main instantiation 7. Whilst the sandbox instantiation 8 running the upgraded application can see the record data record(kn,m), data(kn,m) of the main instantiation 7 up to its creation time tcreate, any changes made within the sandbox instantiation will not modify the record data record(kn,m), data(kn,m) of the main instantiation 7, allowing ensuring accurate quality assurance evaluation 5 results without risking function or integrity of the main instantiation 7. Modifications It will be appreciated that various modifications may be made to the embodiments hereinbefore described. Such modifications may involve equivalent and other features which are already known in the design, configuration and use of systems and methods for establishing computing environments and databases systems more generally, and component parts thereof (whether hardware or software), and which may be used instead of or in addition to features already described herein. Features of one embodiment may be replaced or supplemented by features of another embodiment. In some implementations, a user of the computing environment 6 may be permitted, via client 11a 11b to generate a sandbox instantiation 8 of the computing environment 6 within the main instantiation 7 or an existing sandbox instantiation 8 having a creation time tcreatewhich is: ^ at the present time, i.e. tcreate= t; or ^ at a time in the past, i.e. tcreate< t. Similarly, a read query may also be processed at the present time, or at a time in the past. In this way, the computing environment 6 may leverage the fact that record data record(kn,m), data(kn,m) is not deleted, and that records of validity ranges (for example data(kn,m).ValidRange) are retained, to enable “time-travel” within the data. This may be particularly useful for applications such as, for example, auditing (for technical or other purposes), tracking down bugs (by re-creating a system state corresponding to a report of the bug / issue). A sandbox instantiation 8 may also be merged with a prior state of a different sandbox instantiation 8 or the main instantiation 7. For example, a first sandbox instantiation 8a may be merged with the state of a second sandbox 8b at a time tpast< t in the past by generating a third sandbox instantiation 8c within the second sandbox instantiation with tcreate= tpast, then merging the first 8a and third 8c sandbox instantiations. Although claims have been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure of the present invention also includes any novel features or any novel combination of features disclosed herein either explicitly or implicitly or any generalization thereof, whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as does the present invention. The applicants hereby give notice that new claims may be formulated to such features and / or combinations of such features during the prosecution of the present application or of any further application derived therefrom.

Claims

Claims 1. A system comprising at least one programmable processor and at least one machine-readable medium storing instructions that, when executed by the at least one programmable processor, cause the at least one programmable processor: to permit at least one client to access a computing environment comprising a plurality of components, each component storing record data; to permit the at least one client to generate a sandbox instantiation of the computing environment within a main instantiation of the computing environment or within a previously generated sandbox instantiation of the computing environment to which the at least one client has access; wherein each sandbox instantiation has a creation time; wherein a read query in a given sandbox instantiation returns record data from a timeline of the given sandbox instantiation which matches the read query, wherein the record data from the timeline of the given sandbox instantiation consists of: record data of the given sandbox instantiation which is valid up to a time of the read query; and in a case where the given sandbox instantiation is a direct descendant of the main instantiation, record data of the main instantiation which was valid up to the creation time of the given sandbox instantiation and which is not superseded by record data of the given sandbox instantiation; in a case where the given sandbox instantiation is descendant from the main instantiation via a sequence of one or more antecedent sandbox instantiations: record data of the main instantiation which was valid up to the creation time of an earliest antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations and which is not superseded by record data of the given sandbox instantiation or record data of a sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and for each of the sequence of one or more antecedent sandbox instantiations, record data of that antecedent sandbox instantiation which is not superseded by record data of the given sandbox instantiation or record data of a subsequent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations and which was valid up to the earlier of:the creation time of the next antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and the creation time of the given sandbox instantiation.

2. The system of claim 1, wherein processing modifications made to a component of the plurality of components uses a copy-on-write process.

3. The system of claims 1 or 2, wherein in a case where a modification is made in a given sandbox instantiation to given record data from the timeline of the given sandbox instantiation derived from the main instantiation or from an antecedent sandbox instantiation: the given record data is not modified in the main instantiation or antecedent sandbox instantiation; new record data is added to the given sandbox instantiation to supersede the given record data on the timeline of the given sandbox instantiation.

4. The system of any one of claims 1 to 3, wherein each component comprises metadata.

5. The system of claim 4, wherein in a case where a given component of the plurality of components is configured to generate one or more outputs, metadata of the given component stores one or more output suppression flags corresponding to any or all of the one or more outputs; wherein in a case where the given component of the plurality of components stores one or more output suppression flags, the corresponding outputs generated by the given component in a sandbox instantiation are suppressed or re-directed.

6. The system of any one of claims 1 to 5, wherein the computing environment further comprises one or more global components, each global component storing global data; wherein a read query in a given sandbox returns a union of matching global data and the record data from the timeline of the given sandbox instantiation which matches the read query.

7. The system of any one of claims 1 to 6, wherein one or more of the components store global data in addition to record data; wherein a read query in a given sandbox returns a union of matching global data and the record data from the timeline of the given sandbox instantiation which matches the read query.

8. The system of any one of claims 1 to 7, wherein in response to changing a structure of a given component of the plurality of components within a given instantiation and / or changing a structure of record data of the given component of the plurality of components within the given instantiation, a new version of the given component is generated at a version update time and associated with the given instantiation; wherein: in a case where the version update time and the given instantiation are from a timeline of a given sandbox instantiation, a read query in the given sandbox returns record data of the new version of the given component; in a case where the version update time and the given instantiation are not from the timeline of the given sandbox instantiation, a read query in the given sandbox returns record data of the given component.

9. The system of any one of claims 1 to 8, wherein the at least one client is further permitted to merge a given sandbox instantiation into a target instantiation which is the main instantiation or a different sandbox instantiation which is not the given sandbox instantiation; wherein merging the given sandbox instantiation into the target instantiation comprises modifying record data of the target instantiation based on comparing record data from the timeline of the given sandbox instantiation with: in a case where the target instantiation is the main instantiation, record data of the main instantiation which is valid up to a time of the merge; in a case where the target instantiation is the different sandbox instantiation, record data from the timeline of the different sandbox instantiation.

10. The system of claim 9, wherein merging the given sandbox instantiation into the target instantiation comprises: determining the existence of any conflicts between record data from the timeline of the given sandbox instantiation and: in a case where the target instantiation is the main instantiation, record data of the main instantiation which is valid up to a time of the merge; in a case where the target instantiation is the different sandbox instantiation, record data from the timeline of the different sandbox instantiation; wherein the system is configured, in response to detecting one or more conflicts, for each conflict: to resolve that conflict according to pre-set rules; or to prompt the at least one client to resolve the conflict.

11. The system of claims 9 or 10, wherein the at least one client is further permitted to re-base a given sandbox instantiation to which that at least one client has access, relative to a base instantiation; wherein the base instantiation is the main instantiation or a different sandbox instantiation which is not the given sandbox instantiation; wherein re-basing a given sandbox instantiation comprises: generating a new sandbox instantiation within the base instantiation; merging the given sandbox instantiation into the new sandbox instantiation.

12. The system of any one of claims 1 to 11, wherein the record data of each component comprises at least one data item, each data item comprising: ^ data payload; ^ a data identifier; ^ a sandbox identifier; ^ a start time; and ^ an end time; wherein the data item is valid at or after the start time and before the end time, and wherein ongoing validity is denoted by omitting the end time or by setting the end time to a predetermined ongoing validity value.

13. The system of claim 12, wherein each data item further comprises a global data flag denoting whether that data item is global data.

14. The system of claims 12 or 13, wherein a new data item generated in response to a change made to a given component of the plurality of components within a given sandbox instantiation has a sandbox identifier corresponding to the given sandbox instantiation, and a start time corresponding to the time of the change.

15. The system of any one of claims 12 to 14, wherein in relation to record data from the timeline of the given sandbox instantiation, record data of the given sandbox instantiation which is valid up to a time of the read query corresponds to, for each component of the plurality of components, data items: which have a sandbox identifier corresponding to the given sandbox instantiation; and which have an end time that denotes ongoing validity.

16. The system of any one of claims 12 to 15, wherein in relation to record data from the timeline of the given sandbox instantiation, record data of the main instantiation which was valid up to the creation time of the given sandbox instantiation or up to the creation time of an earliest antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations corresponds to, for each component of the plurality of components, data items: which correspond to the main instantiation; which have a start time before the respective creation time; and which have an end time that: is after the respective creation time; or denotes ongoing validity.

17. The system of any one of claims 12 to 16, wherein in relation to record data from the timeline of the given sandbox instantiation, record data of that antecedent sandbox instantiation which was valid up to the earlier of the creation time of the subsequent antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations and the creation time of the given sandbox instantiation corresponds to, for each component of the plurality of components, data items: which have a sandbox identifier corresponding to that antecedent sandbox instantiation;which have a start time before the respective creation time; and which have an end time that: is after the respective creation time; or denotes ongoing validity.

18. The system of any one of claims 12 to 17, wherein in response to a write request in a given instantiation to store new data corresponding to a given data identifier to a given component of the plurality of components, the system is configured: to generate a new data item in the given component by: storing the new data to the data payload of the new data item; setting the data identifier of the new data item equal to the given data identifier; setting the sandbox identifier to correspond to the given instantiation; and setting the start time equal to the time of the write request; to determine whether the given component includes a pre-existing data item which: has a data identifier matching the given data identifier; has a sandbox identifier corresponding to the given instantiation; has an end time denoting ongoing validity; in response to a positive determination of the pre-existing data item, to set the end time of the pre-existing data item equal to the time of the write request.

19. The system of any one of claims 12 to 18, wherein in response to a deletion request in a given instantiation to delete a given data item from a given component of the plurality of components, the system is configured: In a case where the given data item has a sandbox identifier corresponding to the given instantiation, to set the end time of the given data item to the time of the deletion request; in a case where the given instantiation is a given sandbox instantiation, the given data item belongs to the timeline of the given sandbox instantiation, and the given data item has a sandbox identifier which corresponds to an antecedent instantiation, to generate a new data item in the given component by: storing nothing in the data payload of the new data item, or copying the data payload of the given data item to the data payload of the new data item;setting the data identifier of the new data item to match the given data item; setting the sandbox identifier of the new data item to correspond to the given sandbox instantiation; setting the start time of the new data item equal to a time of the deletion request; and setting the end time of the new data item equal to the time of the deletion request.

20. The system of any one of claims 12 to 19, when depending via claims 9 or 10, wherein merging the given sandbox instantiation into the target instantiation comprises modifying record data of the target instantiation based on data items belonging to a merging set formed by subtracting an intersection of a first set and a second set from a union of the first set and the second set; wherein the first set consists of data items from the timeline of the given sandbox instantiation, and the second set consists of: in a case where the target instantiation is the main instantiation, data items from the main instantiation which are valid up to a time of the merge; in a case where the target instantiation is a different sandbox instantiation from the given sandbox instantiation, data items from the timeline of the different sandbox instantiation.

21. The system of claim 20, wherein modifying record data of the target instantiation based on data items belonging to the merging set comprises, for each given data item belonging to the intersection of the merging set and the first set: determining whether the component corresponding to the given data item comprises one or more pre-existing data items which have a data identifier matching the given data item and a sandbox identifier corresponding to the target instantiation or an antecedent instantiation of the target instantiation; in response to a negative determination, generating a new data item in the component corresponding to the given data item by: copying the data payload and data identifier of the given data item to the new data item; setting the sandbox identifier of the new data item to correspond to the target instantiation; and setting the start time of the new data item equal to the time of the merge.

22. The system of claims 20 or 21, wherein modifying record data of the target instantiation based on data items belonging to the merging set comprises, for each given data item belonging to the intersection of the merging set and the first set: determining whether the second set comprises a pre-existing data item which has a data identifier matching the given data item; in a case of a positive determination of one or more pre-existing data items, determining whether the component corresponding to the given data item comprises a common antecedent data item, wherein a common antecedent data item: has a data identifier matching the given data item; and has a sandbox identifier corresponding to an instantiation which: is an antecedent of the given sandbox instantiation; and is the target instantiation or is an antecedent of the target instantiation; in a case where the determination of the common antecedent data item is negative, flagging the given data item for conflict resolution; in a case where the determination of the common antecedent data item is positive: in a case where the data payload of the common antecedent data item is not the same as the data payload of the pre-existing data item, flagging the given data item for conflict resolution; in a case where the data payload of the common antecedent data item is the same as the data payload of the pre-existing data item: generating a new data item in the component corresponding to the given data item by: copying the data payload and data identifier of the given data item to the new data item; setting the sandbox identifier of the new data item to correspond to the target instantiation; and setting the start time of the new data item equal to the time of the merge; in a case where the sandbox identifier of the pre-existing data item corresponds to the target instantiation, setting the end time of the pre-existing data item equal to the time of the merge.

23. The system of any one of claims 20 to 22, wherein modifying record data of the target instantiation based on data items belonging to the merging set comprises, for each given data item belonging to the intersection of the merging set and the first set: determining whether the component corresponding to the given data item comprises one or more deleted data items having a sandbox identifier corresponding to the target instantiation or an antecedent instantiation of the target instantiation, and a data identifier: which matches the given data item; and which does not match any data item belong to the second set; in response to a positive determination, flagging the given data item for conflict resolution.

24. The system of any one of claims 20 to 23, wherein modifying record data of the target instantiation based on data items belonging to the merging set comprises, for each given data item belonging to the intersection of the merging set and the second set: determining whether the component corresponding to the given data item comprises one or more deleted data items having a data identifier: which matches the given data item; which corresponds to the given sandbox instantiation or an antecedent instantiation of the given sandbox instantiation; and which does not match any data item belong to the first set; in response to a positive determination of one or more deleted data items, determining whether the component corresponding to the given data item comprises a common antecedent data item, wherein a comment antecedent data item: has a data identifier matching the given data item; and has a sandbox identifier corresponding to an instantiation which: is an antecedent of the given sandbox instantiation; and is the target instantiation or is an antecedent of the target instantiation; in a case where the determination of the common antecedent data item is negative, flagging the given data item for conflict resolution; in a case where the determination of the common antecedent data item is positive:in a case where the data payload of the common antecedent data item is not the same as the data payload of the given data item, flagging the given data item for conflict resolution; in a case where the data payload of the common antecedent data item is the same as the data payload of the given data item, setting the end time of the given data item equal to the time of the merge.

25. The system of any one of claims 22 to 24, wherein the system is configured, in response to one or more data items being flagged for conflict resolution, for each given data item flagged for conflict resolution: to process the given data item according to pre-set rules; or to prompt the at least one client to decide how to process the given data item.

26. The system of claim 20, wherein for each given data item belonging to an intersection of the merging set and the first set, the system is configured: to generate a new data item in the component corresponding to the given data item by: copying the data payload and data identifier of the given data item; setting the sandbox identifier to correspond to the target instantiation; and setting the start time equal to the time of the merge; in a case where the second set comprises a pre-existing data item having a data identifier matching the given data item, setting an end time of the pre-existing data item equal to the time of the merge; wherein for each given data item belonging to an intersection of the merging set and the second, the system is configured: to determine whether the component corresponding to the given data item comprises one or more deleted data items having a sandbox identifier corresponding to the given sandbox instantiation or an antecedent instantiation of the given sandbox instantiation, and a data identifier: which matches the given data item; and which does not match any data item belong to the first set; in response to a positive determination, to set the end time of given data item equal to the time of the merge.

27. The system of any one of claims 12 to 26, wherein the data items belonging to each component of the plurality of components are grouped into: a main table comprising the data items which belong to the main instantiation and which are valid at the present time; a history table comprising the data items which belong to the main instantiation and which have an end time before the present time; a shadow table comprising the data items which belong to sandbox instantiations.

28. The system of claim 27, configured to process a read query in a given sandbox instantiation by, for each given component of the plurality of components: determining a sandbox set by filtering a set of all data items matching the read query in the shadow table of the given component to select, for each unique data identifier, the most recent valid data item on the timeline of the given sandbox instantiation; determining a main set by filtering a union of: data items in the main table matching the read query and belonging to the timeline of the given sandbox instantiation; and data items in the history table matching the read query and belonging to the timeline of the given sandbox instantiation, wherein the filtering removes any data items of the main set having a data identifier which matches a data item belonging to the sandbox set; generating a read output set as the union of the main set and the sandbox set.

29. The system of any one of claims 12 to 28, wherein each data item further comprises a deleted flag; wherein in a case where a given data item is deleted in a given instantiation, a new data item is generated in the given instantiation by: storing nothing in the data payload of the new data item, or copying the data payload of the given data item to the data payload of the new data item; setting the data identifier of the new data item to match the given data item; setting the sandbox identifier of the new data item to correspond to the given instantiation; setting the start time of the new data item equal to a time of the deletion request;setting the end time of the new data item to indicate ongoing validity; and setting the deleted flag of the new data item to true; in the case that the given data item has a sandbox identifier corresponding to the given instantiation, setting the end time of the given data item equal to the time of the deletion request.

30. The system of any one of claims 12 to 29, wherein each data item further comprises a validity flag having a binary value, and wherein the system is configured to maintain the validity flags of each given data item such that: in a case where the given data item is the most recent data item corresponding to the combination of data identifier and sandbox identifier matching the given data item, the validity flag of the given item is set to true.

31. The system of any one of claims 1 to 30, wherein the at least one client is permitted, within a given sandbox instantiation to which the at least one client has access, to install or update all or part of a software application which is executable within the given sandbox instantiation of the computing environment.

32. The system of claim 31 when depending via claim 9, configured such that merging the given sandbox instantiation with the target instantiation will cause the installed or updated software application to be executable within the target instantiation of the computing environment.

33. The system of any one of claims 1 to 32, wherein the at least one client is permitted to generate a sandbox instantiation of the computing environment within a main instantiation of the computing environment or within a previously generated sandbox instantiation of the computing environment: at the present time; or at a time in the past.

34. A method executed by at least one programmable processor, comprising: maintaining a computing environment comprising a plurality of components, each component storing record data; permitting at least one client to access the computing environment;permitting the at least one client to generate a sandbox instantiation of the computing environment within a main instantiation of the computing environment or within a previously generated sandbox instantiation of the computing environment to which the at least one client has access; wherein each sandbox instantiation has a creation time; wherein a read query in a given sandbox instantiation returns record data from a timeline of the given sandbox instantiation which matches the read query, wherein the record data from the timeline of the given sandbox instantiation consists of: record data of the given sandbox instantiation which is valid up to a time of the read query; and in a case where the given sandbox instantiation is a direct descendant of the main instantiation, record data of the main instantiation which was valid up to the creation time of the given sandbox instantiation and which is not superseded by record data of the given sandbox instantiation; in a case where the given sandbox instantiation is descendant from the main instantiation via a sequence of one or more antecedent sandbox instantiations: record data of the main instantiation which was valid up to the creation time of an earliest antecedent sandbox instantiation of the sequence of one or more antecedent sandbox instantiations and which is not superseded by record data of the given sandbox instantiation or record data of a sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and for each of the sequence of one or more antecedent sandbox instantiations, record data of that antecedent sandbox instantiation which is not superseded by record data of the given sandbox instantiation or record data of a subsequent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations and which was valid up to the earlier of: the creation time of the next antecedent sandbox instantiation in the sequence of one or more antecedent sandbox instantiations; and the creation time of the given sandbox instantiation.

Images