OMG! You are going to shoot me!!!

I was about to place the start MyXQL under my application’s supervision tree and I found this:

  use Application

  def start(_type, _args) do
    # List all child processes to be supervised
    children = [
      {MyXQL, username: "root", name: :myxql},
      ...

I totally beg your forgiveness and thank you again for all your help!

That is the wrong conclusion. MyXQL should work with any user and you should definitely not use root to login into MySQL. There is some other error here.

Start from the very beginning, it is a very good place to start.
How about testing MyXQL directly:

$ iex -S mix
iex(1)>  {:ok, pid} = MyXQL.start_link([username: "web", password: "something", database: "yourdb", hostname: "localhost"])
{:ok, #PID<0.186.0>}
iex(2)> MyXQL.query(pid, "SELECT count(*) FROM your_table")
{:ok,
 %MyXQL.Result{
   columns: ["count(*)"],
   connection_id: 30,
   last_insert_id: nil,
   num_rows: 1,
   num_warnings: 0,
   rows: [[516]]
 }}

This cuts out anything but MyXQL and tests the parameters directly. I just tested this with a new mix repo (elixir 1.9.1 and erlang 22.1) MyXQL 0.3.0 and MySQL 5.7.28.

Dependency tree of the test repo (because MyXQL depends on DBConnection))

xyxy
└── myxql ~> 0.3.0 (Hex package)
    ├── db_connection ~> 2.0 (Hex package)
    │   └── connection ~> 1.0.2 (Hex package)
    └── decimal ~> 1.6 (Hex package)

I don’t think that’s a fair characterisation. A lot of work went through testing myxql against different combinations of authentication methods, server defaults, ssl, and more, and all that is done through authenticating as different users.

Yes, that’s a very good suggestion. I got caught up thinking it might be configuration issue, but the issue can be something else. In v0.3.0 there’s a bug fix for mysql_native_password authentication (under certain circumstances) and that can be a culprit too.

Classic! (we’ve all been there)