gitbase tables don't get types information in SuperSet

[alexpdp7]

When I explore a gitbase table in SuperSet's SQL Lab, columns are reported as NullType:

I guess this makes the Chart explorer confused, so it cannot detect "time" columns:

, whereas if I do the same on a PostgreSQL metadata table, it works:

[smacker]

Most probably related to #34 and #219

As a temporary workaround, you can go to "datasource editor" and change the type manually.

[alexpdp7]

I just tried updating to v0.24.0-beta3 and the problem persists, I will dig a bit deeper.

[alexpdp7]

It seems that the issue is that Gitbase returns the column types as uppercase, while MariaDB returns them as lowercase. If I hack Superset, adding a .lower() to:

https://github.com/sqlalchemy/sqlalchemy/blob/master/lib/sqlalchemy/dialects/mysql/reflection.py#L190

, types are properly recognized:

However, DATETIME columns, while correctly shown in the interface as such, are still not offered as Time Columns for charts.

edit: I think this is because the hack only applies to certain parts of the UI- if I edit the datasource I still get an unknown type. Changing this in Gitbase should work, I think.

[se7entyse7en]

I've investigated this and I can confirm what @alexpdp7 said about lowercase. Here's the list of matchable types: https://github.com/sqlalchemy/sqlalchemy/blob/master/lib/sqlalchemy/dialects/mysql/base.py#L1146

It's also confirmed in this comment in an issue that was opened by @kuba--.

[se7entyse7en]

@ajnavarro WDYT about this? Can the types be lowercased from gitbase?

[se7entyse7en]

If this is not urgent, maybe this could wait for the migration to gsc and just verify what happens then. wdyt? The problem is that we don't have any eta for gsc migration.

[alexpdp7]

Yeah, it's not a big deal for me- I'm using Postgres now :-p

So I don't mind this being closed (but it's not my decision- perhaps the issue should be moved to the gitbase repo).

[smacker]

Let's keep it open so people can find it easily and we can track the progress on it. Issue in gitbase: src-d/gitbase#962

[smacker]

it was fixed in gitbase master

[se7entyse7en]

The fix landed in gitbase v0.24.0-rc2.

[alexpdp7]

I tried that in my dockerless branch and now I get:

sqlalchemy.exc.CompileError: VARCHAR requires a length on dialect mysql

on the logs, perhaps this should be looked into further.

[se7entyse7en]

@alexpdp7 thanks a lot for retesting this!

[smacker]

the issues should be blocked by the new release of gitbase and this issue: src-d/go-mysql-server#844