Adding support for SingleStore - #968
Conversation
2694ce7 to
97e027d
Compare
| [InlineData("CHAR(36)", "CHAR", false, 36)] | ||
| [InlineData("ENUM('a','b','c')", "ENUM", false, 0)] | ||
| [InlineData("NULL", "NULL", false, 0)] | ||
| [InlineData("TEXT CHARACTER SET utf8 COLLATE utf8_general_ci", "TEXT", false, 0)] |
There was a problem hiding this comment.
Should a test for INT NULL (or INT(11) NULL; what does SingleStore use?) be added here?
There was a problem hiding this comment.
I added a generic NULL test rather than specific ones (see line 209 below)
SingleStore will return INT(11) NULL so the third test on line 186 will test it.
|
https://www.singlestore.com/free-software/ ends in a form to fill out; is there a simple way to spin up a local instance for testing with Docker? No, looks like even the Docker Hub image requires a license key via an environment variable: https://hub.docker.com/r/memsql/cluster-in-a-box May I suggest you make it easier to test SingleStore with just |
|
That's good feedback and it's something we have gone back and forth about over the years. For now if you don't want to create an account I will happily send you a free edition license which will allow the tests to run no problem. If you want to add it to the repo just use a secret variable for the pipelines if that is ok. You can email me for the license if needed: carl at singlestore dot com. |
|
Looks like this PR doesn't handle all the possible differences between SingleStore's DTD_IDENTIFIER and MySQL's. We are investigating and will propose a more suitable fix. Is there a test which runs this code against MySQL directly for conformence testing? |
|
@tavanesov-ua will take this diff over, he is writing a much more robust version of the parser. We should probably also add tests which run directly against SingleStore using our docker container as additional verification. Might do that in a followup PR though. Should have an update here by this time tomorrow. |
It's run indirectly via StoredProcedureTests. IIRC there's no specific test that tests only SQL parsing for stored procedures against a real MySQL server. |
158360c to
6622ceb
Compare
|
MySQL documentation is not strict about which basically means it can contain additional elements which we add in SingleStore, because we support default values and |
|
Nice job @tavanesov-ua - this looks solid to me. @bgrainger what do you think? |
MySQL documentation is not strict about DTD_IDENTIFIER field. It says: The DTD_IDENTIFIER value contains the type name and possibly other information such as the precision or length. So we should not fail on additional elements appearing after the type and parse only known stuff. Signed-off-by: Carl Sverre <carl@singlestore.com>
6622ceb to
b0fccdb
Compare
|
Thanks--I missed that this commit had been rewritten. The new approach looks much more robust (and thanks for the extra tests). I'm concerned about all the extra allocations, but can push some changes to improve that. |
|
Thanks @bgrainger ! |
|
Added in 1.3.7. |
|
@bgrainger thank you! |
3 participants
Hello! I am an engineer at SingleStore (https://www.singlestore.com/). We build a 99% MySQL compatible database which supports scale out workloads. Unfortunately, we detected a small incompatability between one of our information_schema tables and the corresponding table in MySQL. The specific table is called "parameters". In SingleStore we return a trailing NULL for certain types which causes this connector to fail when it later looks up a type called "int NULL" for example.
I hope this patch can be a starting point to making the parser more robust. I am happy to do more testing if required as a blanket "NULL" replace might not be completely safe here. Possibly if NULL Is the only thing left, then we should keep it, but if it's trailing something else then we should remove it. Would love some suggestions.
Thanks for your time and consideration!