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

Broader DBMS support for SMUI (e.g. MySQL<5.7 , MS SQL) #69

Open
pbartusch opened this issue Mar 20, 2021 · 5 comments
Open

Broader DBMS support for SMUI (e.g. MySQL<5.7 , MS SQL) #69

pbartusch opened this issue Mar 20, 2021 · 5 comments

Comments

@pbartusch
Copy link
Collaborator

As PR #67 indicates , there is a demand for a broader DBMS support of SMUI. MySQL<5.7 (5.6) and MS SQL are currently discussed.

To make SMUI's database evolution compatible with other DBMSs adjustment to the database model must be made (see https://github.com/querqy/smui/pull/67/files).

In order to stay compatible with previous SMUI installations , there needs to be a way to migrate existing search management data (best case: automatically), see #67 (comment).

@renekrie
Copy link
Collaborator

How about using an embedded database (like Apache Derby?) and become completely independent from SMUI users' preferences and skills?

@pbartusch
Copy link
Collaborator Author

I think, you describe the SQLite option for SMUI that is already in place. Anyway, persistence with a suitable SLA would need to be established around this database file. From a DevOps perspective that might be a even larger burden than starting an already managed DBMS (like Postgres), in k8s setups like AWS?!

@pbartusch
Copy link
Collaborator Author

pbartusch commented May 14, 2021

Ideation with @mkr :

  • Goal: create a (breaking) new SMUI major with a reset for the DB structure (beginning with a new 1.sql)
  • Step forward - options:
    • Create a read/write API for the data structure of SMUI (current version --> new breaking version)
    • Create an automated database level migration routine (old data structure --> new breaking data structure)

@pbartusch
Copy link
Collaborator Author

This issue would also enable the feature requested with PR #66. #66 will be closed for now (for the same reasons #67 was closed).

fyi: @epugh

@epugh
Copy link
Contributor

epugh commented May 14, 2021

This all makes a lot of sense to me. Thanks for taking the time to come up with a plan.

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

No branches or pull requests

3 participants