Skip to content

Support for an orm data type that allows to pass a group of orm nodes #6799

@agoscinski

Description

@agoscinski

My main motivation is the fact that the lack of support for groups of data is currently influencing design decisions in aiida-workgraph in the syntax. So having at least some prototype of this feature could prevent us to not work around the lack of the feature with a bad syntax.

I use the terms node for the aiida orm node and container for the orm node containing the data.

Ownership

The question of ownership is about who is responsible for the resources in the container? If we delete a container should all elements be also deleted? Using the aiida provenance logic, a container is a result of the incoming data nodes, so the deletion of the container should not affect the incoming nodes. Also since we want to use these containers to apply possibly mutliple operations on them we do not want to copy them for each operation this would explode the database of redundant copies.

-> Container deletion does not delete contained nodes
-> Container is only holding references to the original nodes so no copy

Mutability

As long as the container is not stored, we should be able to delete and add references as we want. Once passed to an operation the container and all its nodes are stored (so read only). What should be however possible is to add stored nodes into a new (not stored) container so the way we reference nodes to container needs to be mutable even after storage.

Access

Since we already concluded that it must the container contains references and not copies, accessing an element in the container gives us back the data node put into the container.

SQL database

Since we concluded that the container deletion does not affect the deletion of the data we can have a many-to-many relationship (one Data is related to many DataContainer and vice-versa).

Provenance Graph

Technically one has to deal with the fact that there are now links between nodes, I am not sure how complicated it is to implement but I don't see an inherent reason that this is not possible.

--> I think with this design it makes more sense to talk about data group instead of container

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions