Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encoding issues with prepared statements and database with utf8_unicode_ci collation #137

Closed
Wijnand opened this issue Sep 22, 2016 · 5 comments

Comments

@Wijnand
Copy link

Wijnand commented Sep 22, 2016

All our databases have utf8_unicode_ci collation and since the upgrade to Ecto2.0 we are having a lot of errors in our queries. I traced it down to mariaex but I am not sure what is wrong here.

I created a gist which illustrates the issue. The query in this gist is very bogus but it should not fail with this error. https://gist.github.com/Wijnand/7ac718d56a440a4bfe0920fad35e3a00

The collation_connection is set to the correct collation so I have no idea why the resulting query fails with: Illegal mix of collations (utf8_unicode_ci,COERCIBLE) and (utf8_general_ci,COERCIBLE) for operation '<'

In the gist I also have a ruby example where I do the exact same thing and this one succeeds. This also wasn't an issue when we were running mariaex 0.6.5.

@squareduck
Copy link

This change introduced the issue
f30200c

Maybe we can find a compromise to satisfy both use cases.

@squareduck
Copy link

squareduck commented Sep 30, 2016

So the option is already there: b1df978

Default is :field_type_var_string and we need :field_type_blob

Need to specify binary encoding in query options or in start_link:

{:ok, conn} = Mariaex.start_link(username: "root", database: "mariaex_collation_test", binary_as: :field_type_blob)

@liveforeverx
Copy link
Member

@Wijnand

Year, this is strange, depending on type. Did it help binary_as: :field_type_blob?

@Wijnand
Copy link
Author

Wijnand commented Oct 10, 2016

Yes, that does help so it is possible to work around this (thanks @squareduck for your investigation).

However I do feel that option should not be the real fix in this case.

@liveforeverx
Copy link
Member

liveforeverx commented Dec 9, 2016

@Wijnand I do not know yet, if there exists better solution yet, because some database configuration need this and some other configuration (I have added documentation for it and marked as important in README).

I would like propose to close this issue now.

And, if you still feel, that there should be better solution, we can reopen new issue with name, like Encoding configuration for different database encoding configuration (or something similar, describing the core problem of configuration types).

@Wijnand Wijnand closed this as completed Dec 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants