Make use of existing or implement own mechanism for handling SQL schema migrations.
Currently there is no mechanism for intelligent handling of SQL schema changes. This could hurt very badly when we have to change or improve the schema. Take a look at Alembic
Activity
assigned to @Jan_Mach
By Jan Mach on 2024-12-26T14:06:11
added C-Dev-Core Done 0% P4 S-New T-Feature labels
changed milestone to %Backlog
Made use of Flask-Migrate plugin built on top of Alembic to enable metadata database migrations.
Relation 'blocks' to: 4275
Relation 'blocks' to: 4367
Relation 'blocks' to: 4383
Relation 'relates' to: 4628
By Jan Mach on 2018-09-20T09:11:24
added Done 50% S-In Progress labels and removed Done 0% S-New labels
-
Maybe useful link: https://docs.sqlalchemy.org/en/latest/core/custom_types.html#creating-new-types
By Pavel Kácha on 2019-01-09T13:35:56
-
The database migrations for IDEA event database mentat_events are now implemented. I have moved this issue to the next release, because there is code already merged in the current development branch that depended performing the migrations on target system. It was a choice of either removing that commit, or going forward with implementation. I have decided to implement it immediately, because this issue is blocking many more features.
More in the attached commit.
By Jan Mach on 2019-01-31T19:01:55
changed milestone to %2.3
-
Cooool!
As I understand it, this is general mechanism, so migrations themselves have to be written by hand, so there is still a possibility to try to switch DDL for Events to SQLAlchemy? Does it still make sense (for help with mig recipes generation, for example)?
By Pavel Kácha on 2019-02-01T09:31:30
-
@ph wrote:
Cooool!
As I understand it, this is general mechanism, so migrations themselves have to be written by hand, so there is still a possibility to try to switch DDL for Events to SQLAlchemy? Does it still make sense (for help with mig recipes generation, for example)?
Yes, it is still possible, but I don`t think it is worth the time and effort now. The alembic is generic enough to work without full database schema and writing the incremental migrations by hand is quite a simple task. It can serve us well for quite some time.
From certain point of view the full SQLAlchemy schema of event database might be useful in many cases (unified database creation, management and cleanup tasks), but I think it should be separate task/issue, because the amount of work is significant.
I have just tested out the migration mechanism for event database on our development server. I consider this issue to be resolved and ready for closing.
By Jan Mach on 2019-02-01T09:44:04
added Done 100% S-Resolved labels and removed Done 75% S-In Progress labels
-
@Jan_Mach wrote:
@ph wrote:
Cooool!
As I understand it, this is general mechanism, so migrations themselves have to be written by hand, so there is still a possibility to try to switch DDL for Events to SQLAlchemy? Does it still make sense (for help with mig recipes generation, for example)?
Yes, it is still possible, but I don`t think it is worth the time and effort now. The alembic is generic enough to work without full database schema and writing the incremental migrations by hand is quite a simple task. It can serve us well for quite some time.
Does it work like having SQLAlchemy schema only allows to use Alembic tools to generate suggestion of migration, which has to be reviewed and handcrafted and incorporated by hand?
From certain point of view the full SQLAlchemy schema of event database might be useful in many cases (unified database creation, management and cleanup tasks), but I think it should be separate task/issue, because the amount of work is significant.
Agreed.
By Pavel Kácha on 2019-02-01T10:01:36
-
@ph wrote:
@Jan_Mach wrote:
@ph wrote:
Cooool!
As I understand it, this is general mechanism, so migrations themselves have to be written by hand, so there is still a possibility to try to switch DDL for Events to SQLAlchemy? Does it still make sense (for help with mig recipes generation, for example)?
Yes, it is still possible, but I don`t think it is worth the time and effort now. The alembic is generic enough to work without full database schema and writing the incremental migrations by hand is quite a simple task. It can serve us well for quite some time.
Does it work like having SQLAlchemy schema only allows to use Alembic tools to generate suggestion of migration, which has to be reviewed and handcrafted and incorporated by hand?
Yes, exactly. When the declarative base model for database is available the option of migration autodetection is available. However this autodetection has its limitations and can not detect all schema changes, so it must be reviewed by developer.
In my opinion the true advantage of having the SQLAlchemy model even for our event database would be in consolidation of database creation and management tasks, which would be awesome and is worth doing sometime, but not within this task.
From certain point of view the full SQLAlchemy schema of event database might be useful in many cases (unified database creation, management and cleanup tasks), but I think it should be separate task/issue, because the amount of work is significant.
Agreed.
By Jan Mach on 2019-02-01T10:07:48
added S-Closed label and removed S-Resolved label