ODA Library Responsibility and Expectations

The ODA Library is imported into the OSO applications to be used to access the database via a common interface, defined by the UnitOfWork and Repository classes. A typical use of the interface is

with oda as uow:
    proposal = uow.prsls.get(prsl_id)

    project = generate_project(proposal)

    persisted_project = uow.prjs.add(project)

    uow.commit()

Below explains what the library offers (and does not offer) for specific pieces of functionality.

Validation

The ODA library does not perform validation on the entity beyond the basic syntactic validation that the Pydantic models provide.

For example, if a Scheduling Block Definition contains an invalid CSP set up, the ODA add method will still store this entity. It is the responsibility of the applications to ensure the validity of the data given the their requirements.

SKUID

The primary entities within OSO are those that can be globally identified by a SKUID. The ODA library will behave in the following way depending on whether it has been passed a Python entity with or without an identifier:

• If the entity passed to add does not have an identifier, the ODA library will generate one using the SKUID library. This entity is then persisted as a new, first version identified by the SKUID.

• If the entity passed to add has a SKUID identifier:

  • If the identifier exists in the database, an update is performed update to that entity.

  • If the identifier does not exist in the database, a new, first version is created identified by the given SKUID.

The final point is enabled so that SKUIDs can be generated client side, which is required for some use cases and makes linking entities easier. However it means developers need to be intentional with how they handle this in the application. For example, if a tool does not generate SKUIDs client side, and offers a POST resource to create a new entity, that resource should validate that an ID is not included in the entity request body.