| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
This makes the docstring example code compatible with both Python 2 and Python 3.
|
|
|
|
| |
exactly
|
|
|
|
| |
here, fixes #3652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
ARRAY type, references #3132
|
|
|
|
|
|
|
|
|
|
|
| |
``<function> WITHIN GROUP (ORDER BY <criteria>)``, using the
method :class:`.FunctionElement.within_group`. A series of common
set-aggregate functions with return types derived from the set have
been added. This includes functions like :class:`.percentile_cont`,
:class:`.dense_rank` and others.
fixes #1370
- make sure we use func.name for all _literal_as_binds in functions.py
so we get consistent naming behavior for parameters.
|
|
|
|
|
|
|
| |
which automatically returns an :class:`.Array` of the correct type
and supports index / slice operations. As arrays are only
supported on Postgresql at the moment, only actually works on
Postgresql. fixes #3132
|
|
|
|
|
|
| |
- any/all work for Array as well as subqueries, accepted by MySQL
- Postgresql ARRAY now subclasses Array
- fixes #3516
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
e.g. the ``func`` construct. Previously, behavior for this method
was undefined. The current behavior mimics that of pre-0.9.4,
which is that the function is turned into a single-column FROM
clause with the given alias name, where the column itself is
anonymously named.
fixes #3137
|
|
|
|
| |
sqlalchemy/orm, sqlalchemy/event, sqlalchemy/testing
|
|
|
|
| |
to get all flake8 passing
|
| |
|
|
|
|
|
|
|
|
|
| |
Removed ungrammatical apostrophes from documentation, replacing
"it's" with "its" where appropriate (but in a few cases with "it is"
when that read better).
While doing that, I also fixed a couple of minor typos etc.
as I noticed them.
|
|
|
|
|
|
|
| |
into the names used by standard functions in :mod:`sqlalchemy.sql.functions`,
such as ``func.coalesce()`` and ``func.max()``. Using these functions
in ORM attributes and thus producing annotated versions of them could
corrupt the actual function name rendered in the SQL. [ticket:2927]
|
| |
|
| |
|
|
|
|
| |
pattern
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the import structure of many core modules.
``sqlalchemy.schema`` and ``sqlalchemy.types``
remain in the top-level package, but are now just lists of names
that pull from within ``sqlalchemy.sql``. Their implementations
are now broken out among ``sqlalchemy.sql.type_api``, ``sqlalchemy.sql.sqltypes``,
``sqlalchemy.sql.schema`` and ``sqlalchemy.sql.ddl``, the last of which was
moved from ``sqlalchemy.engine``. ``sqlalchemy.sql.expression`` is also
a namespace now which pulls implementations mostly from ``sqlalchemy.sql.elements``,
``sqlalchemy.sql.selectable``, and ``sqlalchemy.sql.dml``.
Most of the "factory" functions
used to create SQL expression objects have been moved to classmethods
or constructors, which are exposed in ``sqlalchemy.sql.expression``
using a programmatic system. Care has been taken such that all the
original import namespaces remain intact and there should be no impact
on any existing applications. The rationale here was to break out these
very large modules into smaller ones, provide more manageable lists
of function names, to greatly reduce "import cycles" and clarify the
up-front importing of names, and to remove the need for redundant
functions and documentation throughout the expression package.
|
| |
|
| |
|
|
|
|
| |
- went through examples/ and cleaned out excess list() calls
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
will now be produced via the func.* accessor
as well, as users naturally try to access these
names from func.* they might as well do
what's expected, even though the returned
object is not a FunctionElement.
[ticket:2562]
|
|
|
|
| |
"identifier" in func.
|
|
|
|
|
| |
arguments is easier to understand
- add a test to ensure generic function can have a custom name
|
| |
|
|
|
|
|
|
|
| |
to allow for user-defined GenericFunction
subclasses to be available via the func.*
namespace automatically by classname,
optionally using a package name as well.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a Sequence object as its argument and renders the
appropriate "next value" generation string on the
target platform, if supported. Also provides
".next_value()" method on Sequence itself.
[ticket:2085]
- added tests for all the conditions described
in [ticket:2085]
- postgresql dialect will exec/compile a Sequence
that has "optional=True". the optional flag is now only
checked specifically in the context of a Table primary key
evaulation.
- func.next_value() or other SQL expression can
be embedded directly into an insert() construct,
and if implicit or explicit "returning" is used
in conjunction with a primary key column,
the newly generated value will be present in
result.inserted_primary_key. [ticket:2084]
|
| |
|
|
|
|
|
| |
a consistent tag
- AUTHORS file
|
|
|
|
|
|
|
|
|
| |
to be compared to another set, typically with IN against
composite primary keys or similar. Also accepts an
IN with multiple columns. The "scalar select can
have only one column" error message is removed - will
rely upon the database to report problems with
col mismatch.
|
|
|
|
|
|
|
|
| |
- Function rolls the various standalone execution functionality of CC into itself,
accesses its internal state more directly
- collate just uses _BinaryExpression, don't know why it didn't do this already
- added new _Case construct, compiles directly
- the world is a happier place
|
|
|
|
|
|
|
| |
class. It can be subclassed to provide user-defined
SQL functions in an imperative style, including
with pre-established behaviors. The postgis.py
example illustrates one usage of this.
|
|
|
|
| |
[ticket:1244]
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Documentation has been converted to Sphinx.
In particular, the generated API documentation
has been constructed into a full blown
"API Reference" section which organizes
editorial documentation combined with
generated docstrings. Cross linking between
sections and API docs are vastly improved,
a javascript-powered search feature is
provided, and a full index of all
classes, functions and members is provided.
|
|
|
|
|
|
|
| |
class to reduce dependencies
- implemented _generative decorator for select/update/insert/delete constructs
- other minutiae
|
|
|
|
|
|
|
|
|
|
| |
which basically allows for their return type to be determined
automatically. Helps with dates on SQLite, decimal types,
others. [ticket:1160]
- added decimal.Decimal as an "auto-detect" type; bind parameters
and generic functions will set their type to Numeric when a
Decimal is used.
|
| |
|
| |
|
|
|
|
| |
to a single, streamlined "_populate_column_collection" method called for all selectables
|
| |
|