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

sql: test/evaluate compatibility with Flowable #31879

Open
awoods187 opened this issue Oct 25, 2018 · 13 comments

Comments

5 participants
@awoods187
Copy link
Contributor

commented Oct 25, 2018

Test flowable with CockroachDB
https://www.flowable.org/

@knz knz changed the title Test Flowable sql: test/evaluate compatibility with Flowable Nov 12, 2018

@knz knz moved this from Triage to Backlog in (DEPRECATED) SQL Front-end, Lang & Semantics Nov 21, 2018

@rolandcrosby

This comment has been minimized.

Copy link
Collaborator

commented Feb 12, 2019

Right off the bat, #32098 blocks several of Flowable's CREATE TABLE statements. I ran Flowable against Postgres for a while and captured a sample of queries that it uses; will continue to work with the SQL team to determine how to identify other compatibility gaps.

@awoods187

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2019

Any update on this after Friday's testing @rolandcrosby ?

@drewdeally

This comment has been minimized.

Copy link

commented Feb 19, 2019

@awoods187

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2019

Remaining items:

@knz

This comment has been minimized.

Copy link
Member

commented Feb 21, 2019

#35109 we can probably work around easily. #35108 is a little more work but is probably doable for 19.1, or perhaps 19.1.x. I wouldn't recommend backports to 2.1.

@knz

This comment has been minimized.

Copy link
Member

commented Feb 21, 2019

The linked support issue also mentions #32098.

This is a well-scoped, well-contained new feature that's approximately M-sized (compare to S-sized for the previous two)

@rolandcrosby

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2019

I'm 90% sure that #32098 is the only query here that's specific to Flowable. The other two are caused by pg_dump and do not occur in the Flowable application.

(What happened here: we ran Flowable against a Postgres instance that was configured to write all queries to a log file, then ran pg_dump to save the state of the database for later import/analysis; Postgres still had query logging turned on when we ran pg_dump, so all the SQL queries issued by pg_dump also showed up in the log, along with all the queries that were actually issued by the Flowable application.)

@knz

This comment has been minimized.

Copy link
Member

commented Feb 21, 2019

For #32098 it would be good to know whether the customer uses any other precision than 6 in their app.

@rolandcrosby

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2019

The Postgres schemas in Flowable only use TIMESTAMP and TIMESTAMP(6). You can search that repo online here; I downloaded the code locally to look in more detail. There are a couple occurrences of TIMESTAMP(3) in the repo, but those are only in the MySQL-specific DDL code.

@awoods187

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2019

Does that impact your idea @knz ?

@knz

This comment has been minimized.

Copy link
Member

commented Feb 21, 2019

we won't be able to do anything about TIMESTAMP(3) in the near future. For the other cases, my PR #35128 might help. It's only going to work as long as they don't expect the precision to be preserved in information_schema/pg_catalog.

@rolandcrosby

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2019

I believe your PR will solve the problem. Thanks!

@drewdeally

This comment has been minimized.

Copy link

commented Feb 21, 2019

Roland, we can work around these with the create script - if we don't go that route then Flowable needs to have logic to add indexes for RI constraints and they will also fail.
Unless we have a plan for FK constraint to automate the index build on the reference col and table when not present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.