[ ] JSONTest issue #52, 87 failures due to lack of dialect support for JSON type
[ ] IdentityColumnTest the errors comes from the fact that one column of this test's table is named "desc" which collides with the SQL Standard DESC keyword.
[ ] IdentityAutoincrementTest same as IdentityColumnTest
[ ] CTETests use the INSERT INTO for tables with recursive keys (create table foo (id int primary key, num int references foo(id));) which is known to not work properly in Monet (https://github.com/MonetDB/MonetDB/issues/6131) e.g. insert into foo values (1,null), (2,1); raises FOREIGN KEY constraint 'foo.foo_num_fkey' violated
[ ] QuotedNameArgumentTests are failing because of the NOT supported column CHECK constraint. Of course this is not raising an error or an exception but simply issues a warning through MonetDB dialect compiler so the user would know that the CHECK is a no-op. The problem comes from the fact that for the testing suite the SAWarnings are turned into errors (see. sqlalchemy/testing/warnings.py). Another issue with this group of tests is that we do not support comment_reflection which, I guess, was supposed to be supported given the fact that we support _COMMENT_s for SQL objects.
Errors
JSONTestissue #52, 87 failures due to lack of dialect support for JSON typeIdentityColumnTestthe errors comes from the fact that one column of this test's table is named "desc" which collides with the SQL StandardDESCkeyword.IdentityAutoincrementTestsame asIdentityColumnTestCTETests use theINSERT INTOfor tables with recursive keys (create table foo (id int primary key, num int references foo(id));) which is known to not work properly in Monet (https://github.com/MonetDB/MonetDB/issues/6131) e.g.insert into foo values (1,null), (2,1);raisesFOREIGN KEY constraint 'foo.foo_num_fkey' violatedQuotedNameArgumentTests are failing because of the NOT supported column CHECK constraint. Of course this is not raising an error or an exception but simply issues a warning through MonetDB dialect compiler so the user would know that the CHECK is a no-op. The problem comes from the fact that for the testing suite the SAWarnings are turned into errors (see.sqlalchemy/testing/warnings.py). Another issue with this group of tests is that we do not supportcomment_reflectionwhich, I guess, was supposed to be supported given the fact that we support _COMMENT_s for SQL objects.Failures
!=needs to be translated properly. #51