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

feat(pg): Support CockroachDB #2531

Merged
merged 11 commits into from
Oct 9, 2022
Merged

feat(pg): Support CockroachDB #2531

merged 11 commits into from
Oct 9, 2022

Conversation

yevgenypats
Copy link
Member

Summary

CockroachDB is PostgreSQL compliant but there always some differences so this PR address those and adds it to the testing workflow.

Closes #1710

@yevgenypats yevgenypats removed the request for review from a team October 8, 2022 22:03
case pgTypeCockroachDB:
return c.SchemaTypeToCockroach(t)
default:
return c.SchemaTypeToPg10(t)
Copy link
Collaborator

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

Copy link
Member Author

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/

@bbernays
Copy link
Collaborator

bbernays commented Oct 8, 2022

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

@yevgenypats
Copy link
Member Author

yevgenypats commented Oct 9, 2022

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 driver/library per plugin .

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.

Copy link
Contributor

@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.

The code looks good, but a few comments:

  1. [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 breaking CockroachDB when we change Postgres and vice versa. Also we could de-couple the tests.

  2. [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?

  3. [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?

  4. [blocking] Looks like there a few differences for CockroachDB:

@yevgenypats
Copy link
Member Author

The code looks good, but a few comments:

  1. [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 breaking CockroachDB when we change Postgres and vice versa. Also we could de-couple the tests.
  2. [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?
  3. [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?
  4. [blocking] Looks like there a few differences for CockroachDB:
  • 1 primary key
  1. I don't think we should separate it, pgx has the save driver and so should we. If we are breaking something in pg it means we are doing something wrong as for an insertion plugin it really should work for both.
  2. Configuration is the same for cockroachDB as this is basically the idea behind Cockroach
  3. I don't think we should keep minimal support at 11 because it is just artificial version. our policies are not related to data types supported at insertion time so for policies we should mention that is is minimum 11 but not for a pg destination when it is clearly working for 10. If we will see in the code that we are starting to put a lot of effort to support 10 then sure we can drop it but at the moment this works out-of-the-box
  4. This is a PostgreSQL limitation as well it can have only one primary key (it can be composite - and the same in cockroach). The only different that you rightfully mentioned is that cockroach must have a pk and this is already solved as we have _cq_id for the exact reason when we don't have other pks. The other thing we might want to do is to alter the pk in transaction and/or use alter statement - but this is a best practices actually also for PostgreSQL so I'll push this in the PR.

@yevgenypats
Copy link
Member Author

yevgenypats commented Oct 9, 2022

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.

Copy link
Contributor

@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.

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 {
Copy link
Contributor

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?

Copy link
Member Author

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.

@yevgenypats yevgenypats added the automerge Automatically merge once required checks pass label Oct 9, 2022
@yevgenypats
Copy link
Member Author

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

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)

@erezrokah
Copy link
Contributor

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 :)

@kodiakhq kodiakhq bot merged commit 0b4c2c1 into main Oct 9, 2022
@kodiakhq kodiakhq bot deleted the feat/pg/cockroachdb branch October 9, 2022 12:25
kodiakhq bot pushed a commit that referenced this pull request Oct 9, 2022
🤖 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).
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.

Add Support For CockroachDB
4 participants