| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: I4e8c2aa8fe817bb2af8707410fa0201f938781de
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixed regression in JSON datatypes where the "literal processor" for
a JSON index value, that needs to take effect for example within DDL,
would not be invoked for the value. The native String and Integer
datatypes are now called upon from within the JSONIndexType
and JSONPathType. This is applied to the generic, Postgresql, and
MySQL JSON types.
Change-Id: Ifa5f2acfeee57a79d01d7fc85d265a37bd27c716
Fixes: #3765
|
| |
|
|
|
|
|
|
|
|
| |
this must have been an oversight. Leave mysql.JSON in place still
as we might need to add things to it.
- CAST(json, String) still confusing MySQL drivers even mysqlclient.
Since here we're checking for the raw form of the JSON and not a typical
round trip, add a force for unicode
Change-Id: I727f4526a01a0875037cf0dede45cd074da5205a
|
| | |
|
|
|
persistence of JSON values in MySQL as well as basic operator support
of "getitem" and "getpath", making use of the ``JSON_EXTRACT``
function in order to refer to individual paths in a JSON structure.
fixes #3547
- Added a new type to core :class:`.types.JSON`. This is the
base of the PostgreSQL :class:`.postgresql.JSON` type as well as that
of the new :class:`.mysql.JSON` type, so that a PG/MySQL-agnostic
JSON column may be used. The type features basic index and path
searching support.
fixes #3619
- reorganization of migration docs etc. to try to refer both to
the fixes to JSON that helps Postgresql while at the same time
indicating these are new features of the new base JSON type.
- a rework of the Array/Indexable system some more, moving things
that are specific to Array out of Indexable.
- new operators for JSON indexing added to core so that these can
be compiled by the PG and MySQL dialects individually
- rename sqltypes.Array to sqltypes.ARRAY - as there is no generic
Array implementation, this is an uppercase type for now, consistent
with the new sqltypes.JSON type that is also not a generic implementation.
There may need to be some convention change to handle the case of
datatypes that aren't generic, rely upon DB-native implementations,
but aren't necessarily all named the same thing.
|
