Refactor server start-up options #418
Conversation
Previously, the repository server used one and the same folder for loading data during start-up and storing it persistently. This resulted in a mixture of input AAS/Submodel files (AASX, JSON and XML) and persistently stored AAS/Submodel files from the `LocalFileObjectStore` (JSON). This separates the server's input and storage into two different directories to prevent their files being mixed. Moreover, the option to overwrite existing AAS/Submodels in the storage got added and the option to persistently store data got adapted. In accordance with the new changes, the `README` and `Dockerfile` were adapted to present the changes to the end users. Fixes eclipse-basyx#404
|
I suppose the CI fails due to #417? Edit: Disregard this. |
| class WSGIApp(ObjectStoreWSGIApp): | ||
| def __init__(self, object_store: model.AbstractObjectStore, file_store: aasx.AbstractSupplementaryFileContainer, | ||
| base_path: str = "/api/v3.0"): | ||
| base_path: str = "/api/v3.0/"): |
There was a problem hiding this comment.
Why did you add a trailing slash here? It seems to work, but seems unintuive, as all endpoint definitions begin with a slash.
There was a problem hiding this comment.
My initial idea was this: https://developers.google.com/search/blog/2010/04/to-slash-or-not-to-slash. But you are right, I would have to adapt the other paths too (even tho WSGI can handle it). I will just undo the change.
| def sync_input_to_storage( | ||
| input_files: DictObjectStore, | ||
| storage_files: LocalFileObjectStore, | ||
| overwrite: bool | ||
| ) -> Tuple[int, int, int]: | ||
| """ | ||
| Merge :class:`Identifiables <basyx.aas.model.base.Identifiable>` from an in-memory | ||
| :class:`~basyx.aas.model.provider.DictObjectStore` into a persistent | ||
| :class:`~basyx.aas.backend.local_file.LocalFileObjectStore`. | ||
| :param input_files: In-memory :class:`~basyx.aas.model.provider.DictObjectStore` | ||
| :param storage_files: Persistent :class:`~basyx.aas.backend.local_file.LocalFileObjectStore` | ||
| :param overwrite: Flag to overwrite existing :class:`Identifiables <basyx.aas.model.base.Identifiable>` in the | ||
| :class:`~basyx.aas.backend.local_file.LocalFileObjectStore` | ||
| :return: Counts of processed :class:`Identifiables <basyx.aas.model.base.Identifiable>` as | ||
| ``(added, overwritten, skipped)`` | ||
| """ | ||
|
|
||
| added, overwritten, skipped = 0, 0, 0 | ||
| for identifiable in input_files: | ||
| if identifiable.id in storage_files: | ||
| if overwrite: | ||
| existing = storage_files.get_identifiable(identifiable.id) | ||
| storage_files.discard(existing) | ||
| storage_files.add(identifiable) | ||
| overwritten += 1 | ||
| else: | ||
| skipped += 1 | ||
| else: | ||
| storage_files.add(identifiable) | ||
| added += 1 | ||
| return added, overwritten, skipped |
There was a problem hiding this comment.
I think this method should go to model.provider in the SDK, with AbstractObjectStore as both input and output types, as it is general enough to warrant such a location.
Alternatively (and even better), add this as a AbstractObjectStore.sync_with(other: AbstractObjectStore, overwrite: bool) method to the AbstractObjectStore itself.
There was a problem hiding this comment.
Is the method generic enough to be of interest to end users of the SDK? I thought it would only be relevant to the current use case involving the server.
2 participants
Previously, the repository server used one and the same folder for loading data during start-up and storing it persistently. This resulted in a mixture of input AAS/Submodel files (AASX, JSON and XML) and persistently stored AAS/Submodel files from the
LocalFileObjectStore(JSON).This separates the server's input and storage into two separate directories, preventing their files from being mixed. Moreover, the option to overwrite existing AAS/Submodels in the storage was added and the option to persistently store data was adapted. In accordance with the new changes, the
READMEandDockerfilewere adapted to present the changes to the end users.Fixes #404