Skip to content

Conversation

@yevgenypats
Copy link
Contributor

@yevgenypats yevgenypats commented Feb 8, 2023

Blocked by cloudquery/plugin-sdk#668

This streamlines migrations, introduce force option and in general should speed up migrations substantially as we only do now one query instead of query per table.

Blocked by another take in SDK - cloudquery/plugin-sdk#688

@yevgenypats yevgenypats marked this pull request as ready for review February 8, 2023 13:54
kodiakhq bot pushed a commit to cloudquery/plugin-sdk that referenced this pull request Feb 8, 2023
This adds diff methods for `Table`. This will help simplify migrations so we can transform the destination/database into `Table` struct and then understand what was changed/added in the same way across all destination plugins.

PostgreSQL PR example - cloudquery/cloudquery#7819
Copy link
Contributor

@candiduslynx candiduslynx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I sense that there are issues with the append mode now (_cq_id was used as PK there).

sql := "alter table " + pgx.Identifier{table.Name}.Sanitize() + " alter column " + pgx.Identifier{col}.Sanitize() + " set not null"
if _, err := c.conn.Exec(ctx, sql); err != nil {
return fmt.Errorf("failed to set not null on column %s on table %s: %w", col, table.Name, err)
if c.enabledPks() && !table.IsPrimaryKeyEqual(pgTable) {
Copy link
Member

@hermanschaaf hermanschaaf Feb 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may want to move this check to be above the GetAddedColumns check, so that no changes are made to the table if migrate-forced is false and a forced migration is necessary. Otherwise the table can be left in a half-migrated state. (Either that or move the added columns first, so that the user only needs to manually do the forced operations.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why it's half baked? but I can't move it up because potentially the primary keys are on the columns that were just added.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok yeah you are right. I now moved that check up to fail early.

switch t {
case "boolean":
return schema.TypeBool
case "bigint", "integer":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I guess there is some information lost in the conversion here because our types don't map 1:1 to postgres 🤔 So if you have a source table and write it back to postgres, the schemas won't match exactly (integers will become bigints). In this case it's fine, but hopefully we don't run into irreconcilable cases in other databases...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. I guess we need to transform the incoming tables to pgtables so we can compare them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think in this case it's fine until we add BigInt type to our type system but if the information loss is the otherway around then we will need to transform first the Table -> DbTable and only then compare what we got from database table.

Copy link
Member

@hermanschaaf hermanschaaf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like the query to select all tables is not accounting for tables with composite PKs in the way we expect

@yevgenypats yevgenypats force-pushed the feat/pg_better_migrations branch from d769e8a to 722d997 Compare February 11, 2023 09:29
kodiakhq bot pushed a commit to cloudquery/plugin-sdk that referenced this pull request Feb 12, 2023
For each test in the destination testing suite we use unique table now.

This should solve the bug I've hit this PR - cloudquery/cloudquery#7819
kodiakhq bot pushed a commit to cloudquery/plugin-sdk that referenced this pull request Feb 16, 2023
Migration detection APIs take 2.

- This creates **one** API that returns all the changes instead of multiple growing APIs for different set of changes.
- Improves Migration tests for different use-cases

This will come up also with a Postgres PR and documentation PR:

Basically each destination plugin would have the following table:

Migrations Logic

|  Change  | Behaviour                                        |
|----------|----------------------------------|
|  Add Column | Auto Migrate/Drop Table         | 
|  Add Column with Not Null | Auto Migrate/Drop Table  |  
|  Remove Column | Auto Migrate/Drop Table  |
|  Remove Column with Not Null | Auto Migrate/Drop Table  |
|  Change Column |  Auto Migrate/Drop Table |

and we can easily expand it in the code, tests and documentations.

Example of usage in cloudquery/cloudquery#7819
Copy link
Member

@erezrokah erezrokah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see anything blocking 🚀 I'm still testing, but if you'd like to merge I think that's fine and we can follow up with fixes if we have them

Copy link
Member

@erezrokah erezrokah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, found a bug

@yevgenypats yevgenypats added the automerge Automatically merge once required checks pass label Feb 16, 2023
@kodiakhq kodiakhq bot merged commit 8f51733 into main Feb 16, 2023
@kodiakhq kodiakhq bot deleted the feat/pg_better_migrations branch February 16, 2023 14:47
return schema.TypeByteArray
case "text[]":
return schema.TypeStringArray
case "timestamp without time zone":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will only become a problem with CDC, but at some point we'll also need to support (or at least handle without panicking?) all the other postgres types, like timestamptz.

kodiakhq bot pushed a commit that referenced this pull request Feb 16, 2023
🤖 I have created a release *beep* *boop*
---


## [2.1.0](plugins-destination-postgresql-v2.0.10...plugins-destination-postgresql-v2.1.0) (2023-02-16)


### Features

* **pg:** Faster migrations ([#7819](#7819)) ([8f51733](8f51733))


### Bug Fixes

* **deps:** Update module github.com/cloudquery/plugin-sdk to v1.36.0 ([#7809](#7809)) ([c85a9cb](c85a9cb))
* Postgresql timestamps ([#7840](#7840)) ([e2c8b61](e2c8b61))

---
This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
kodiakhq bot pushed a commit that referenced this pull request Feb 19, 2023
kodiakhq bot pushed a commit that referenced this pull request Feb 28, 2023

#### Summary

Same as #7819 for MSSQL.

This is a breaking change due to the type change from `datetimeoffset` to `datetime2` as we don't want to save time zone offset, see https://github.com/cloudquery/cloudquery/blob/ee4b2c01867b2140537ee4656d943d2e0cf2898b/plugins/destination/postgresql/client/types.go#L74

I suggest following the code in an IDE as it's hard to understand the changes from the diff.

BEGIN_COMMIT_OVERRIDE
feat(deps): Update MSSQL plugin-sdk to v1.38.2

BREAKING-CHANGE: Update MSSQL plugin-sdk to v1.38.2. You'll need to drop the database and start fresh due to a change in the schema for all timestamp columns from `datetimeoffset` to `datetime2`.
END_COMMIT_OVERRIDE

<!--
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automerge Automatically merge once required checks pass

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants