| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| | |
needs to be explicit here since tablestest sticks testing.db onto metadata.bind
|
| | |
| |
| |
| | |
why moving it broke the oracle/postgres builds
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
for cursor.lastrowid would not function correctly
in conjunction with :attr:`.ResultProxy.inserted_primary_key`.
|
| | |
|
| |
|
|
| |
a lower-case-t table
|
| |
|
|
|
|
| |
- other cleanup
- don't need compat.decimal, that approach never panned out. hopefully
outside libs aren't pulling it in, they shouldn't be
|
| | |
|
| |
|
|
|
| |
for now
- fix up adaptation tests to still try to exercise the correlation argument
|
| |
|
|
|
|
| |
ability for correlation to have any effect for a SELECT that's stated
in the FROM.
- add a new exhaustive test suite for correlation to test_compiler
|
| |
|
|
| |
so it can be managed more easily
|
| |
|
|
| |
don't exist in the superquery.
|
| |\
| |
| |
| | |
cymysql support
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
now accommodate an empty list as an instruction to not create/drop
any items, rather than ignoring the collection. [ticket:2664].
This is a behavioral change and extra notes to the changelog
and migration document have been added.
- create a new test suite for exercising codepaths
in engine/ddl.py
|
| |/
|
|
|
|
| |
just
too much for now
|
| | |
|
| |
|
|
| |
- start filling in default versions of remaining requirements that are still only in test/
|
| |
|
|
| |
- add suite tests for basic explicit Sequence support, result-row column access (tests that name_normalize is set correctly among many other things)
|
| |
|
|
|
|
|
|
| |
could impact some usages of the new :func:`.orm.remote` and
:func:`.orm.local` annotation functions, where annotations
could be lost when the column were used in a subsequent
expression.
[ticket:2660]
|
| | |
|
| |
|
|
|
| |
values of ``None`` to :func:`.null`.
[ticket:2496]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
:class:`.SchemaType` ``inherit_schema``. When set to ``True``,
the type will set its ``schema`` attribute of that of the
:class:`.Table` to which it is associated. This also occurs
during a :meth:`.Table.tometadata` operation; the :class:`.SchemaType`
is now copied in all cases when :meth:`.Table.tometadata` happens,
and if ``inherit_schema=True``, the type will take on the new
schema name passed to the method. The ``schema`` is important
when used with the Postgresql backend, as the type results in
a ``CREATE TYPE`` statement. [ticket:2657]
|
| |
|
|
|
|
| |
:class:`.Column` had both a foreign key as well as an
alternate ".key" name for the column. Also in 0.7.10.
[ticket:2643]
|
| |
|
|
|
| |
insert().returning() raises an informative CompileError if attempted
to compile on a dialect that doesn't support RETURNING.
|
| |
|
|
|
|
|
|
| |
functions, in addition to straight columns. Common modifiers
include using ``somecolumn.desc()`` for a descending index and
``func.lower(somecolumn)`` for a case-insensitive index, depending on the
capabilities of the target backend.
[ticket:695]
|
| | |
|
| |
|
|
|
|
|
|
|
| |
:class:`.CheckConstraint` would apply itself back to the
original table during a :meth:`.Table.tometadata` operation, as
it would parse the SQL expression for a parent table. The
operation now copies the given expression to correspond to the
new table.
[ticket:2633]
|
| |
|
|
|
|
|
|
|
|
| |
without passing the "for_update=True" flag would apply the default
object to the server_default, blowing away whatever was there.
The explicit for_update=True argument shouldn't be needed with this usage
(especially since the documentation shows an example without it being
used) so it is now arranged internally using a copy of the given default
object, if the flag isn't set to what corresponds to that argument.
Also in 0.7.10. [ticket:2631]
|
| |
|
|
|
|
| |
than the size of actual column identifiers would fail to render
the columns correctly in a SELECT statement.
[ticket:2610]
|
| | |
|
| | |
|
| |
|
|
|
| |
an INSERT that's used in executemany() as opposed to one which has a VALUES
clause with multiple entries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- update "not supported" messages for empty inserts, mutlivalue inserts
- rework the ValuesBase approach for multiple value sets so that stmt.parameters
does store a list for multiple values; the _has_multiple_parameters flag now indicates
which of the two modes the statement is within. it now raises exceptions if a subsequent
call to values() attempts to call a ValuesBase with one mode in the style of the other
mode; that is, you can't switch a single- or multi- valued ValuesBase to the other mode,
and also if a multiple value is passed simultaneously with a kwargs set.
Added tests for these error conditions
- Calling values() multiple times in multivalue mode now extends the parameter list to
include the new parameter sets.
- add error/test if multiple *args were passed to ValuesBase.values()
- rework the compiler approach for multivalue inserts, back to where
_get_colparams() returns the same list of (column, value) as before, thereby
maintaining the identical number of append() and other calls when multivalue
is not enabled. In the case of multivalue, it makes a last-minute switch to return
a list of lists instead of the single list. As it constructs the additional lists, the inline
defaults and other calculated default parameters of the first parameter
set are copied into the newly generated lists so that these features continue
to function for a multivalue insert. Multivalue inserts now add no additional
function calls to the compilation for regular insert constructs.
- parameter lists for multivalue inserts now includes an integer index for all
parameter sets.
- add detailed documentation for ValuesBase.values(), including careful wording
to describe the difference between multiple values and an executemany() call.
- add a test for multivalue insert + returning - it works !
- remove the very old/never used "postgresql_returning"/"firebird_returning" flags.
|
| |\ |
|
| | |
| |
| |
| | |
visit_NUMERIC see #2618
|
| | |
| |
| |
| |
| | |
so that they can be compared in ``__nonzero__`` prior to their
self_group() step. [ticket:2621]
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some databases support this syntax for inserts:
INSERT INTO table (id, name) VALUES
('v1', 'v2'),
('v3', 'v4');
which greatly increases INSERT speed.
It is now possible to pass a list of lists/tuples/dictionaries as
the values param to the Insert construct. We convert it to a flat
dictionary so we can continue using bind params. The above query
will be converted to:
INSERT INTO table (id, name) VALUES
(:id, :name),
(:id0, :name0);
Currently only supported on postgresql, mysql and sqlite.
|
| |
|
|
|
|
|
|
| |
where because we've decided
that "lowercase" is the case insensitive casing, we can't distinguish between case insensitive/not
on a database that returns case-insensitive names as UPPERCASE, for names that are UPPERCASE.
[ticket:2615]
|
| | |
|
| |
|
|
| |
are being tested (when I know) b/c it wasn't initially clear to me why case was being toggled everywhere, etc.
|
| | |
|