Prevent or improve error message when mixing drivers

[cvogt]

It seems to happen every once in a while that people accidentally use different Slick drivers for defining their table classes and for running queries, especially when using different databases in development, testing and production.

Here is one of several instances from the mailing list: https://groups.google.com/forum/#!searchin/scalaquery/TypeInfo/scalaquery/8zghyUwEONo/-GMkrE2Xm8gJ

We should either prevent this problem statically or at least throw a better error message.

[cvogt]

related to #48

[david-wilson]

What's the best option for dealing with this? I am writing my app against Postgres, but trying to use H2 for the tests, using the PostgresQL mode. I receive the error referenced in the mailing list thread.

[cvogt]

Make sure you import the same driver when defining your table and where you run queries (i.e. where you use Database and withSession. You can use the cake pattern for that. If you use the code generator you can extend the generated Tables trait and set the profile member to the required driver. Does that help?

[david-wilson]

I'm using the play-slick plugin, so I am not explicitly defining a driver outside my configuration. I am not sure how to extend the Tables trait in this case. I can provide code, if needed.

[szeiger]

BTW, I did some work on this recently in https://github.com/slick/slick/tree/tmp/scalatypes-in-drivers. It needs to be rebased on top of the fast path converters work and I'm not sure if it's the right direction in general, but it would solve this issue.

[cvogt]

@david-wilson if you provide code that reproduces the issue for you, I can take a look

[cvogt]

Another instance: #744

[szeiger]

No, #744 is about using the wrong driver for a database. There's no (cheap, non-hacky) way to prevent this.

[cvogt]

He creates a column, which comes from a Table, which comes from a driver. Invoker or else could check that you run a query against the same driver you used to define it and throw a useful exception if not. Doesn't seem hacky to me. Am I missing something?

[szeiger]

But that is the case there, everything is run with H2Driver, just the database connection and JDBC driver is for Postgres.

[cvogt]

Ok, not the exact problem, but related. Mixing wrong combinations of Slick and JdbcDrivers. We could emit a warning (that can be disabled) if somebody doesn't use the jdbc driver we expect, or even better pick the right jdbc driver by default and let people override it. In almost all cases people use exactly the same driver (or 1 out of 2 in case of sqlserver). Better than failing with weird behavior like #744.

[szeiger]

No, we couldn't, because in real world applications we don't even see the driver. The Connection comes from a pool.

[cvogt]

good point... mh... on the other hand, people stumble over these problems when trying slick, which is not a "real world application" but an important use case for Slick adoption. So I still think this check makes sense.

[cvogt]

Another instance where somebody had problems with configuring the Slick driver together with the corresponding jdbc driver. https://groups.google.com/d/msgid/scalaquery/b07a1215-768a-4638-8050-3561dca4c4ba%40googlegroups.com

We should really pick a default jdbc driver for a slick driver in my eyes!

[nafg]

Maybe the slick drivers could provide shorthand Database factories, that
preselect the driver class, and maybe let you specify the connection string
without the jdbc prefix boilerplate. The methods could have distinct names
and only exist in the concrete drivers. They could even be different for
different drivers, for instance some could take the values that the
connection string needs and build the connection string for you. And
database types that have multiple jdbc drivers could have separate methods
for each.
On Apr 10, 2014 7:50 AM, "Jan Christopher Vogt" notifications@github.com
wrote:

Another instance where somebody had problems with configuring the Slick
driver together with the corresponding jdbc driver.
https://groups.google.com/d/msgid/scalaquery/b07a1215-768a-4638-8050-3561dca4c4ba%40googlegroups.com

We should really pick a default jdbc driver for a slick driver in my eyes!

Reply to this email directly or view it on GitHubhttps://github.com//issues/670#issuecomment-40069137
.

[szeiger]

I wouldn't want to provide such methods unless we add connection pooling out of the box. We shouldn't encourage users not to use a connection pool.

[cvogt]

Another instance where subtle mixing up drivers lead to a lot of confusion: #794

[cvogt]

Here is another instance. http://stackoverflow.com/questions/24460628/slick-2-delete-row-in-slick-with-play-framework/24460790?noredirect=1#comment37865825_24460790

[cvogt]

Related to #419

[szeiger]

As pointed out in #801, this looks like a bug in play-slick. You're supposed to use the injected singleton driver there, and if you do that consistently, none of these problems should occur.