jimsmart / schema Goto Github PK

Suggested by @gnewton — see golang/go#7408 (comment)

Looking at your API your schema.Table(..) does not expose a Table.PrimaryKeys(), which I would certainly find useful (similar to https://docs.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html#getPrimaryKeys(java.lang.String,%20java.lang.String,%20java.lang.String). I would also find a Table.ForeignKeys() to be useful. 👍 :-) Thanks.

Originally part of #1

We need a method to obtain the name of the schema that a given table belongs to.

schema package looks lack of support for index metadata.

I am testing using the following sqlserver image.

 sqlserver:
    image: mcr.microsoft.com/mssql/server:2017-latest-ubuntu
    container_name: sqlserver
    volumes:
      - sqlserverdata:/var/opt/mssql 
    ports:
      - "1434:1433"
    environment:
      - ACCEPT_EULA=Y 
      - MSSQL_PID=Developer
      - SA_PASSWORD=8jkGh47hnDw89Haq8LN2

The queries for getting colum types in the various dialect_{{type}}.go are

mssql 
`SELECT * FROM %s WHERE 1=0`,

vs

mysql
`SELECT * FROM %s LIMIT 0`,

Some real examples,

mssql 
SELECT * FROM Vehicle WHERE 1=0

mssql 
SELECT * FROM `Vehicle` WHERE 1=0
 "Incorrect syntax near '`'."

mysql
SELECT * FROM `Vehicle`  LIMIT 0

I would think that the dialect_mysql.go should account for the back-ticks. I haven't tested this on a mysql image, so I don't know for sure.

`SELECT * FROM `%s` LIMIT 0`,

Upstream customers of the schema library, for all database types, are passing in

"`"+tablename+"`"

where they should have just been passing in

tablename

Whose responsibility is it to know the different variations of a tablename?
upstream customers or the schema library?

If its the schema library then we have a breaking change because upstream libraries are passing in

"`"+tablename+"`"

Currently, setting up the necessary databases for testing is a manual process, it should be automated/standardised using Docker-compose.

Re #14

Support for Snowflake database is difficult to test because it is a commercial service with no open/free offering (beyond a free trial).

Should they ever offer a free test account for open source software that chooses to support their product, then we should implement tests for this db/driver in Travis CI.

Travis is setup to build nightly, and has been successfully building for some time.

Without changes, builds are now failing. For example https://travis-ci.org/jimsmart/schema/builds/650973349 — this is bad because the badge on the main page says builds are failing, when technically it's just a CI config issue (the code builds and runs just fine)/

Builds are failing on Travis currently because the build attempts to launch all of the Docker db images for a single build, and the tests run before the dbs are up.

I have started work to split each db (and driver) into a separate build on a separate branch, because this was anticipated, but that work isn't quite finished.

The local Docker setup now includes Oracle support, including a script to create a Docker Oracle image.

But this is not currently used on Travis.

We need a solution to be able to test against an Oracle database on Travis / similar. I'm not attached to Travis if we can find another CI provider with Oracle support.

Perhaps this will work https://github.com/cbandy/travis-oracle — I've not tried.

Migrated from previous #12

The problem is described in the referenced issue.
smallnest/gen#17

https://github.com/jimsmart/schema/blob/master/dialect.go#L32.

The work done to address #4, does not include Oracle database.

Currently users of the package are not protected from API changes.

Should we make package schema into a Go module?

Are there any negative aspects associated with such a change?