Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss initial data creation #245

Closed
jsangmeister opened this issue May 11, 2023 · 3 comments · Fixed by #332
Closed

Discuss initial data creation #245

jsangmeister opened this issue May 11, 2023 · 3 comments · Fixed by #332
Assignees
Labels
Milestone

Comments

@jsangmeister
Copy link
Contributor

When the datastore starts and the create_initial_data command is set (see https://github.com/OpenSlides/openslides-datastore-service/blob/main/docs/development.md#initial-data-creation) and the datastore is empty, the datastore inserts initial data to have a functioning state. The initial data file can be provided manually by setting DATASTORE_INITIAL_DATA_FILE and defaults to the current one under https://github.com/OpenSlides/openslides-backend/blob/main/global/data/initial-data.json.

This may however be wrong, e.g. if a feature branch has a lower backend MI than the current initial data file. We could think about how to improve this. A few notes to consider:

  • Theoretically, the feature branch should always be based on the main one. So, if the feature branch has a lower MI than the main one, a simple merge/rebase is required anyway and should solve the problem after removing the current database and re-inserting the initial data.
  • It is possible to manually overwrite the intial data file. For situations where this is only needed once or for a short time, one can add the line DATASTORE_INITIAL_DATA_FILE=https://raw.githubusercontent.com/OpenSlides/openslides-backend/main/global/data/example-data.json (with the link replaced by the version you'd like) to the datastore writer section in the docker compose file.
  • The datastore does not have any knowledge of the other services, so it is not possible to directly link to the local backend version. We would need to introduce a make command analogous to the backend's make run-dev-local where it is required to have the backend in ../openslides-backend and where the file is then mounted into the datastore container and used as the initial data file, but I think this would be overkill. The other option would be to move this functionality from the datastore to the backend: The backend starts and checks if the datastore is empty (the datastore would need a new dev-only route for this). If it is empty, the backend does the insertion of the initial data via the existing action organization.initial_import. I think this would be the cleanest solution, but also requires some changes to datastore and backend.
@r-peschke
Copy link
Member

IMO we should have a make run-dev-local in openslides anyway, but to use *all local repositories.
Apart of this IMO we should think about concentrating the whole initiation, migration and database definition management including models.yml and generation in one service. IMO this will be the better approach for the relational database feature.

@ostcar
Copy link
Member

ostcar commented May 23, 2023

@normanjaeckel It would be nice if you could be part of this discussion

@jsangmeister jsangmeister modified the milestones: 4.1, 4.x Dec 12, 2023
@jsangmeister
Copy link
Contributor Author

jsangmeister commented Mar 12, 2024

Discussed with @peb-adr and @m-schieder with the additional context of OpenSlides/OpenSlides#6745 as well as the burden of currently having to manually/programmatically call openslides initial-data after instance startup. We will go with the latter approach of moving this functionality to the backend, using its local initial data file, and removing the functionality from the datastore completely. This has a few advantages:

  • The backend uses its relation handling to ensure a valid initial data file, which the datastore cannot do.
  • The backend must not fetch the file from github or have it mounted, it can simply use the local file.
  • The datastore might become obsolete in the near future. Moving this functionality will happen anyway in this case, so it saves work to cumulate the changes now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants