fix #230: Fix schema (in)sensitive casing issue

[wokket]

Had some merge issues but think I'm there.

Assorted changes to DBMS's that are (generally) case insensitive.

PGSql is a little interesting with case-sensitive tables but case insensitive schemas (as currently implemented), but so be it.

There's possibly an option to bypass the Exists checks entirely for those DBMS's that support create table if not exists syntax, but that's a bridge too far for me time-wise atm.

[wokket]

G'day @erikbra , just wondering if there's anything holding up this fix from your side? I tried to convert another existing Roundhouse/SQL server project to grate recently and still have to force v1.3.2 to get it to work... Hoping this and a few other fixes will get me closer to the line

[erikbra]

Hi, @wokket - thanks for being patient. No, nothing other than myself holding this up (but that is a big enough hurdle by itself sometimes). I resolved some merge conflicts, and I'm waiting for the tests to run, and I'm ready to merge if they run as they should.

It's been hard to prioritise a lot of time on grate the last months, sorry.

[erikbra]

Seems like tests are failing on MariaDB and SqlServer, unfortunately, @wokket

[wokket]

Probably not surprising after nearly 9 months 🤣

I'll try and see what's going on when I get a chance... I definitely feel like focussing on closing out some of these bugs/weirdness/idiosyncrasies that have crept in is a good thing.

[wokket]

OK, after fighting with inconsistent test runs locally for a few hours I think we still have some stuff to sort out here.

In the current main codebase, we are still applying a case-sensitive check for whether the grate schema exists, regardless of server casing rules, so #230 is still in play :(

The new check for whether a table (like Version) exists is now applying a case-_in_sensitive search, regardless of server casing rules, which means the scenario I'm testing here (run a migration against a schema, then again a second time with different casing, replicating what we did to try and upgrade our roundhouse project to grate) fails because the exists check for Version says it exists, but all the following uses of the table fail as it can't find the table as passed-in.

Do we want to change the table exists checks to return both the schema and table as found in the database and use that for the rest of the migration?

I understand the case-insensitive lookups as a workaround for bug #245, and keeping back-compat with existing database already migrated is obviously paramount, but it feels like forcing case insensitivity in some places, and respecting the target casing rules are fundamentally incompatible :(

[cocytus]

Related: After one year, I don't think i issue #245 is actually fixed for postgres. I tried the latest 1.5.4 release, and exactly as a year ago, grate creates "ScriptsRun[Error]" and "Version" tables, even though "scriptsrun" and "version" exists.

[erikbra]

This one should be solved by. other means now :)