| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
One test appears to use some awkward calling style
with the current_date function that isn't working in pg10
anymore, this looks like an extremely
old test that can be removed
Change-Id: I5f8aee0f5ed423461be5a9060c812eb0acdc7df5
|
|
|
|
|
|
|
|
| |
Fixes: #3429
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I870ee7dc801d553c5309c291402ec468b671e9a9
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/383
|
|
|
|
|
|
|
|
| |
tested using pycodestyle version 2.2.0
Fixes: #3885
Change-Id: I5df43adc3aefe318f9eeab72a078247a548ec566
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/343
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
``<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
|
|
|
|
|
|
|
| |
of :class:`.FunctionElement` or other column element that incorrectly
states 'None' or any other invalid object as the ``.type``
attribute will report this exception instead of recursion overflow.
fixes #3485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructs are now importable from the "from sqlalchemy" namespace,
just like every other Core construct.
- The implicit conversion of strings to :func:`.text` constructs
when passed to most builder methods of :func:`.select` as
well as :class:`.Query` now emits a warning with just the
plain string sent. The textual conversion still proceeds normally,
however. The only method that accepts a string without a warning
are the "label reference" methods like order_by(), group_by();
these functions will now at compile time attempt to resolve a single
string argument to a column or label expression present in the
selectable; if none is located, the expression still renders, but
you get the warning again. The rationale here is that the implicit
conversion from string to text is more unexpected than not these days,
and it is better that the user send more direction to the Core / ORM
when passing a raw string as to what direction should be taken.
Core/ORM tutorials have been updated to go more in depth as to how text
is handled.
fixes #2992
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
- apply autopep8 + manual fixes to most of test/sql/
|
|
|
|
| |
Found using: https://github.com/intgr/topy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is currently being supported in addition to nose, and will likely
be preferred to nose going forward. The nose plugin system used
by SQLAlchemy has been split out so that it works under pytest as
well. There are no plans to drop support for nose at the moment
and we hope that the test suite itself can continue to remain as
agnostic of testing platform as possible. See the file
README.unittests.rst for updated information on running tests
with pytest.
The test plugin system has also been enhanced to support running
tests against mutiple database URLs at once, by specifying the ``--db``
and/or ``--dburi`` flags multiple times. This does not run the entire test
suite for each database, but instead allows test cases that are specific
to certain backends make use of that backend as the test is run.
When using pytest as the test runner, the system will also run
specific test suites multiple times, once for each database, particularly
those tests within the "dialect suite". The plan is that the enhanced
system will also be used by Alembic, and allow Alembic to run
migration operation tests against multiple backends in one run, including
third-party backends not included within Alembic itself.
Third party dialects and extensions are also encouraged to standardize
on SQLAlchemy's test suite as a basis; see the file README.dialects.rst
for background on building out from SQLAlchemy's test platform.
|
|
|
|
|
|
|
| |
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]
|
|
|
|
|
|
| |
https://bitbucket.org/zzzeek/sqlalchemy_informixdb
- remove informix, maxdb, access symbols from tests etc.
|
|
|
|
| |
- went through examples/ and cleaned out excess list() calls
|
|
|
|
|
|
| |
- other cleanup
- don't need compat.decimal, that approach never panned out. hopefully
outside libs aren't pulling it in, they shouldn't be
|
|
|
|
|
|
|
| |
become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.
|
|
|
|
|
|
|
|
|
| |
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]
|
|
|
|
|
|
|
|
|
|
| |
True by default, if not passed explicitly,
on bindparam() if the "value" or "callable"
parameters are not passed.
This will cause statement execution to check
for the parameter being present in the final
collection of bound parameters, rather than
implicitly assigning None. [ticket:2556]
|
|
|
|
| |
"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.
|
| |
|
| |
|
|
|
|
|
|
|
| |
classes to a new test.lib.fixtures module
- move testing.TestBase to test.lib.fixtures
- massive search and replace
|
| |
|
|
|
|
| |
fixed list. window functions need parens
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- add --with-cdecimal flag to tests, monkeypatches cdecimal in
- fix mssql/pyodbc.py to not use private '_int' accessor in decimal conversion
routines
- pyodbc version 2.1.8 is needed for cdecimal in any case as
previous versions also called '_int', 2.1.8 adds the same string
logic as our own dialect, so that logic is skipped for modern
pyodbc version
- make the imports for "Decimal" consistent across the whole lib. not sure
yet how we should be importing "Decimal" or what the best way forward
is that would allow a clean user-invoked swap of cdecimal; for now,
added docs suggesting a global monkeypatch - the two decimal libs
are not compatible with each other so any chance of mixing produces
serious issues. adding adapters to DBAPIs tedious and adds in-python
overhead. suggestions welcome on how we should be doing
Decimal/cdecimal.
|
| |
|
|
|
|
| |
classes (e.g. fixes func.text()). [ticket:1798]
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
API, used for any expression construct that can be sent to
execute(). FunctionElement now inherits Executable so that
it gains execution_options(), which are also propagated
to the select() that's generated within execute().
Executable in turn subclasses _Generative which marks
any ClauseElement that supports the @_generative
decorator - these may also become "public" for the benefit
of the compiler extension at some point.
|
|
|
|
|
|
|
|
|
|
|
| |
same way any func.foo() construct is, with automatic
SELECT being applied when passed to execute().
- The "type" and "bind" keyword arguments of a func.foo()
construct are now local to "func." constructs and are
not part of the FunctionElement base class, allowing
a "type" to be handled in a custom constructor or
class-level variable.
|
| |
|
|
See README.unittests for information on how to run
the tests. [ticket:970]
|