-
Notifications
You must be signed in to change notification settings - Fork 499
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(pg): Support CockroachDB #2531
Conversation
case pgTypeCockroachDB: | ||
return c.SchemaTypeToCockroach(t) | ||
default: | ||
return c.SchemaTypeToPg10(t) |
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.
I thought our minimum supported pg version was 11
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.
I tested it locally, we should change our Postgresql In CI to 10. there is no feature in 11 right now that we use that is not available in 10. https://www.postgresql.org/about/featurematrix/
Overall this looks good. My question is why add support for Cockroach DB to the PG plugin destination? Why not make a standalone plugin for CockroachDB? That way we can add any special optimizations to each plugin without worrying about breaking the other |
Our pg plugin should work with cockroachdb out of the box. The whole point of CockroachDB is that is is PG compliant. Right now we have 95% of the same code so unless the plugin will turn into 50% code for Cockroach and 50% for DB only then we should look into splitting this. It's even the same driver ('pgx'). A good rule of thumb should be Also this way it provides good user experience so users can use the same plugin for both and less work for us to maintain duplicate documentation and releases. |
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.
The code looks good, but a few comments:
-
[non-blocking] Shouldn't this be a separate destination plugin? I get that the logic is mostly the same, but maybe we can re-use the code via a shared module, etc?Saw that you commented to @bbernays but I'd rather duplicate the code first and then pull the duplication into a shared library. That way we won't need to worry about breakingCockroachDB
when we change Postgres and vice versa. Also we could de-couple the tests. -
[non-blocking] How would the configuration for
CockroachDB
look like? Looks like the same and we auto detect the DB type. Maybe better to be explicit and set the DB type in the spec? -
[blocking] I'd keep the minimal requirement as Postgres 11, at least until we verify all of our policies queries work on 10 (or modify them to do so). Is 10 a requirement for this PR?
-
[blocking] Looks like there a few differences for
CockroachDB
:
- It can have only 1 primary key. And dropping a key needs to be via a single transaction. Do we need to handle it in
c.logger.Info().Str("table", table.Name).Msg("Recreating primary keys") - Maybe there are some other changes too but I'll need to test a bit more
|
In anycase even if we will split in the future due to unforseen requirements/constraints I don't think we should do it now given how easy it is to support both with current constraints/requirements. So basically let's go with the easy solution first and then see if any requirements will come up that will require splitting it and much more work. |
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.
Assuming this doesn't break Postgres I think we can give it a go, though I would maybe keep it as a hidden feature until we can do more testing on it
return nil | ||
} | ||
|
||
func (c *Client) setNullOnPks(ctx context.Context, table *schema.Table) error { |
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.
Should this be called setNotNullOnPks
?
Also let's say someone changes an existing column to be a primary key and it has a null value. What will happen? Will this fail and if so, how do we handle this failure?
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.
Yes this will fail. we don't have (and will never have) a way to deal with that. The user will have to either drop the table or migrate columns to contain non-null.
auto-migrations can fail in data integrations platform so it's best effort and it is acceptable/industry standard as maintaining migrations for all databases*all_apis is not really feasible.
Thanks! I don't think this will break Postgres and I wouldn't keep it under feature flag as otherwise no one will be able to help us test it (I think just one or two users asked for it - so now we wait for people to try out so we can fix the bugs) |
Yeah, no need for a flag, "hidden" means no documentation for it :) |
🤖 I have created a release *beep* *boop* --- ## [1.1.0](plugins-destination-postgresql-v1.0.1...plugins-destination-postgresql-v1.1.0) (2022-10-09) ### Features * **pg:** Support CockroachDB ([#2531](#2531)) ([0b4c2c1](0b4c2c1)) ### Bug Fixes * **deps:** Update plugin-sdk for postgresql to v0.12.10 ([#2556](#2556)) ([571346e](571346e)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Summary
CockroachDB is PostgreSQL compliant but there always some differences so this PR address those and adds it to the testing workflow.
Closes #1710