selda icon indicating copy to clipboard operation
selda copied to clipboard

Validation tests fail with Postgresql >=13 & when same database used for other schemas

Open YPares opened this issue 3 years ago • 1 comments

Validation/migration tests on master fail with Postgresql 13.7, 14.4 and 14.5.

(Running stack test --flag selda-tests:postgres)

### Error in:   1:query tests:36:validateTable validates
selda-tests> ValidationError "error validating table \"people\":\ntable has inconsistent columns:\n  \"name\":\n    column is called \"age\" in database\n    column should have type `TText', but actually has type `TInt64' in database\n    column is not indexed in database, even though it should be\n  \"age\":\n    column is called \"cash\" in database\n    column should have type `TInt64', but actually has type `TFloat' in database\n    column is indexed in database, even though it shouldn't be\n  \"pet\":\n    column is called \"name\" in database\n    column is not nullable in database, even though it should be\n    column is indexed in database, even though it shouldn't be\n  \"cash\":\n    column is called \"pet\" in database\n    column should have type `TFloat', but actually has type `TText' in database\n    column is nullable in database, even though it shouldn't be\n    column is not indexed in database, even though it should be\n"
### Error in:   3:mutable tests:41:drop column migration
selda-tests> ValidationError "error validating table \"table1\":\ntable has inconsistent columns:\n  \"col_0\":\n    column is called \"col_1\" in database\n    column should have type `TText', but actually has type `TInt64' in database\n  \"col_1\":\n    column is called \"col_0\" in database\n    column should have type `TInt64', but actually has type `TText' in database\n"

YPares avatar Oct 05 '22 13:10 YPares

I experience the same problem when the database is also used by another application (and creates tables in another schema). I think the reason is because in selda-postgresql, pgGetTableInfo doesn't order the columns obtained from information_schema.columns based on the ordinal_position. So you can make no assumption that these columns will be returned in the same order than the fields of the Haskell datatype.

YPares avatar Oct 13 '22 12:10 YPares