Commits
This allows type extensions to be registered at runtime via the
`:ecto_sqlite3, extensions:` configuration key, which takes a list
of modules that implement the `Extension` behaviour.
* update Ecto to v3.13
* add identifier/1 support
* link identifier/1 in changelog
* pin ecto_sql to ~> 0.13.0
* drop :literal clause
* Make map encoding configurable
* Make array encoding configurable
* Add changelog entry
We will simply rescue the exception thrown by both libraries and return
a simple `:error` to keep the interface consistent. We will need to keep
an eye on upstream changes in Ecto as support for both `JSON` and `Jason`
evolve.
closes: #159
I personally believe this is incorrect to handle decode / encode this
way, but upstream in myxql and postgrex this is how it is handled.
Rather than fight that issue, I will instead make it behave similarly.
Fixes #158
We will check the config at runtime now instead of relying on it being
compiled as having the type set.
Fixes #157
Some SQL syntax does not pass a table prefix (atom or string)
In the case of `create_name`, then third param may be a string or atom
prefix ... and in those cases should be treated as a prefix.
However syntax such as `VALUES (...)` will pass in the values list
information as the third tuple. this was causing spurious exceptions
to be thrown, rather than creating the correct table name
Introduce `assert_valid_join` which checks for unsupported join syntax
This improves the error messages for `JOIN VALUES (...) AS` clauses
which were being mistakenly tagged as a table prefixing issue. Now the
user gets a more accurate message.
It also puts all the join syntax checking into a single function which
makes it a bit eaiser to reason about (e.g. that hints, values, etc. are
not OK, but other join constructs are)
1. **Pass `mode: :immediate` to `Repo.transaction/2`:** Use this approach to set
the transaction mode for individual transactions.
2. **Define custom transaction functions:** Create wrappers, such as
`Repo.immediate_transaction/2` or `Repo.deferred_transaction/2`, to easily
apply different modes where needed.
3. **Set a global default:** Configure `:default_transaction_mode` to apply a
preferred mode for all transactions.
I went ahead and added in support for cell-wise support for bounded
values. This has been on the todo list for a while.
fixes: #152
Thank you @krwenholz for pointing this out.
closes: #116
Some SQL syntax does not pass a table prefix (atom or string)
In the case of `create_name`, then third param may be a string or atom
prefix ... and in those cases should be treated as a prefix.
However syntax such as `VALUES (...)` will pass in the values list
information as the third tuple. this was causing spurious exceptions
to be thrown, rather than creating the correct table name
Introduce `assert_valid_join` which checks for unsupported join syntax
This improves the error messages for `JOIN VALUES (...) AS` clauses
which were being mistakenly tagged as a table prefixing issue. Now the
user gets a more accurate message.
It also puts all the join syntax checking into a single function which
makes it a bit eaiser to reason about (e.g. that hints, values, etc. are
not OK, but other join constructs are)
1. **Pass `mode: :immediate` to `Repo.transaction/2`:** Use this approach to set
the transaction mode for individual transactions.
2. **Define custom transaction functions:** Create wrappers, such as
`Repo.immediate_transaction/2` or `Repo.deferred_transaction/2`, to easily
apply different modes where needed.
3. **Set a global default:** Configure `:default_transaction_mode` to apply a
preferred mode for all transactions.