-
Notifications
You must be signed in to change notification settings - Fork 144
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
feat: Add systemdb support for MS SQL Server #6167
feat: Add systemdb support for MS SQL Server #6167
Conversation
👷 Deploy request for meltano pending review.Visit the deploys page to approve it
|
Hi @JulesHuisman awesome to see you pick this back up, personally very excited to get some support for other DB's into Meltano 🥳 @aaronsteers this is a continuation of this thread: https://gitlab.com/meltano/meltano/-/issues/3315#note_908238671, I think what @JulesHuisman has here plus some docs covering how to use "unofficial backends like MSSQL and MySQL" are a great start and easy way to test the water. We could follow it up and setup an actions workflow to test migrations against MySQL/MSSQL when a PR with new migrations is created. @aaronsteers In the original thread you'd expressed some concerns about being able to test against MSSQL, looks like the MSSQL on linux docker container is pretty popular and well-supported (https://hub.docker.com/_/microsoft-mssql-server), but just having a GH actions gate for migrations would go along way towards ensuring that future migrations don't having breaking changes for MySQL or MSSQL. |
@JulesHuisman and @pandemicsyn - I would be happy to add CI tests for DBs. I am also okay to merge this and add those tests in a follow-on issue, depending on @JulesHuisman's availability and/or others who can help ship this in CI. A quick google search shows tests may be fairly pretty easy in GitHub Actions - https://datastation.multiprocess.io/blog/2021-12-16-sqlserver-in-github-actions.html |
src/meltano/migrations/versions/13e8639c6d2b_add_state_edit_to_job_state_enum.py
Show resolved
Hide resolved
@pandemicsyn and @edgarrmondragon - I'm removing myself from reviewer role but please re-add me if you would like me to rereview. I'll defer to you both - when you feel this is ready to merge, I'm all for it. 👍 And - again - since risk here is super low (adding str max when where they were otherwise omitted), I'm okay to merge without additional CI checks added. The one thing I'd ask to watch out for is that I'd rather a stringlen max be overly permissive than to run a risk of truncating or failing on use cases that might introduce longer strings. (Most modern data platforms don't have any benefit to shorter lengths anyway, since they only use the num bytes that each row requires.) |
Correct mapping of SQLAlchemy models to migration scriptsJobsPlugin Settings
|
@pandemicsyn we used to have a sort of test matrix running tests on both SQLite and PostgreSQL:
I suggest we migrate those (either before or after this PR merges) and include both MySQL and MSSQL in the mix. |
Thanks for taking a look guys, In some places it might be possible to make the max string length longer. I chose 128 because in some places MYSQL would throw errors when it was longer (450). I can also take a look at testing the migrations. The MSSQL docker container works quite well, I also used it when developing this PR. |
@edgarrmondragon @pandemicsyn Hi guys, what needs to be fixed or adjusted to get this PR through? And do we want the tests included in this PR, or can that be included in a separate PR? Thanks! |
@JulesHuisman can you merge |
Codecov Report
@@ Coverage Diff @@
## main #6167 +/- ##
==========================================
+ Coverage 96.52% 96.55% +0.02%
==========================================
Files 95 96 +1
Lines 8349 8500 +151
Branches 398 405 +7
==========================================
+ Hits 8059 8207 +148
Misses 227 227
- Partials 63 66 +3
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
Ah alright, so it is running into issues with the string length. I will look into it! |
…ulesHuisman/meltano into 3238-broader-system-db-support
@JulesHuisman an options seems to be off with the mssql service, and it's causing all workflows to fail. We moved away from the |
Ah yes, looks good! I will merge the new main branch and switch over mssql and mysql. (I think my health check needs a health check itself 😃) |
Hi @JulesHuisman! First of all, thanks for this awesome work! I just had to include a small change to make it work in my environment in the The new file looks like this after the changes: import sqlalchemy as sa
from alembic import op
from meltano.migrations.utils.dialect_typing import (
get_dialect_name,
max_string_length_for_dialect,
)
# revision identifiers, used by Alembic.
revision = "5b43800443d1"
down_revision = "13e8639c6d2b"
branch_labels = None
depends_on = None
def upgrade():
dialect_name = get_dialect_name(op)
max_string_length = max_string_length_for_dialect(dialect_name)
op.alter_column("job", "job_id",
new_column_name="job_name",
existing_type=sa.types.String(max_string_length)
)
op.rename_table("job", "runs")
def downgrade():
dialect_name = get_dialect_name(op)
max_string_length = max_string_length_for_dialect(dialect_name)
op.rename_table("runs", "job")
op.alter_column("job", "job_name",
new_column_name="job_id",
existing_type=sa.types.String(max_string_length)
) After this change, I managed to make the db migration work with a MySQL instance. |
@joaopamaral thanks for sharing! I've put your changes in diff format in case @JulesHuisman or someone else wants to try them out: import sqlalchemy as sa
from alembic import op
+from meltano.migrations.utils.dialect_typing import (
+ get_dialect_name,
+ max_string_length_for_dialect,
+)
+
# revision identifiers, used by Alembic.
revision = "5b43800443d1"
down_revision = "13e8639c6d2b"
def upgrade():
- op.alter_column("job", "job_id", new_column_name="job_name")
+ dialect_name = get_dialect_name(op)
+ max_string_length = max_string_length_for_dialect(dialect_name)
+
+ op.alter_column("job", "job_id",
+ new_column_name="job_name",
+ existing_type=sa.types.String(max_string_length)
+ )
op.rename_table("job", "runs")
def downgrade():
+ dialect_name = get_dialect_name(op)
+ max_string_length = max_string_length_for_dialect(dialect_name)
+
op.rename_table("runs", "job")
- op.alter_column("job", "job_name", new_column_name="job_id")
+ op.alter_column("job", "job_name",
+ new_column_name="job_id",
+ existing_type=sa.types.String(max_string_length)
+ ) |
Heads up @JulesHuisman: I'm gonna merge |
@pandemicsyn @aaronsteers this is ready for review for MSSQL support! |
bf09f4d
to
9edbb6f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! 🥳
Thanks @edgarrmondragon, I like the idea of moving the Mysql code to another branch. That created a really weird bug in testing which I could not figure out. |
@JulesHuisman I started a draft PR #6528, but I (or someone else) need to take some to debug those failing state tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work here! Very excited to get this in!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments but I'm approving assuming those can get fixed so it's not a blocker
Thanks for taking this over the finish line @edgarrmondragon! |
Relates to issue #3238.
The main improvement is limiting all String types in the alembic migrations. This allows the possibility to use both MSSQL and MYSQL as a Meltano backend database.
Both databases were manually tested. It might be valuable to add automatic tests to the Github actions.
To use MYSQL run:
pip install mysqlclient
To use MSSQL run:
pip install pyodbc