| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
| |
elements with a ``__clause_element__()`` method properly.
[ticket:2849]
Conflicts:
lib/sqlalchemy/sql/elements.py
|
| |
|
|
|
|
|
|
|
|
|
|
| |
so that the custom type isn't exposed to an operation that is against the
"impl" type's constraint, [ticket:2842]
- this change showed up as some recursion overflow in pickling with labels,
add a __reduce__() there....pickling of expressions is less and less something
that's very viable...
Conflicts:
lib/sqlalchemy/sql/elements.py
lib/sqlalchemy/sql/sqltypes.py
|
| |
|
|
| |
suddenly hitting this.
|
| |
|
|
|
|
|
|
|
|
|
| |
mssql to ensure that any literal SQL expression values are
rendered directly as literals, instead of as bound parameters,
within a CREATE INDEX statement. [ticket:2742]
- don't need expression_as_ddl(); literal_binds and include_table
take care of this functionality.
Conflicts:
lib/sqlalchemy/sql/util.py
|
| |
|
|
|
|
|
|
|
| |
typically via in-place mutation, will raise an informative error
message rather than causing a recursion overflow.
[ticket:2815]
Conflicts:
lib/sqlalchemy/sql/selectable.py
|
| |
|
|
|
|
|
|
|
|
| |
:func:`.foreign` on a :class:`.Column` before association with a parent
:class:`.Table` could produce issues related to the parent table not
rendering within joins, due to the inherent copy operation performed
by an annotation. [ticket:2813]
Conflicts:
lib/sqlalchemy/sql/elements.py
|
| |
|
|
| |
with CreateColumn rules
|
| |
|
|
|
|
|
|
|
| |
compilation rule which allows skipping of columns, by producing
a rule that returns ``None``. Also in 0.8.3.
Conflicts:
doc/build/changelog/changelog_09.rst
lib/sqlalchemy/sql/ddl.py
|
| |
|
|
|
|
| |
cherry pick of 9302be39a5f40b537ff43e1990c7a210c464cf1c from 0.9
Conflicts:
lib/sqlalchemy/sql/selectable.py
|
| |
|
|
|
|
|
|
| |
not be properly quoted if it was referred to in multiple FROM clauses.
Also in 0.8.3, 0.7.11. [ticket:2801]
Conflicts:
doc/build/changelog/changelog_09.rst
|
| |
|
|
|
| |
produces the negation of the expression "IN" returns
when used against an empty collection. Also in 0.8.3.
|
| |
|
|
|
|
| |
used only as an ``alias()`` construct, it would not render using the
WITH keyword. Also in 0.7.11.
[ticket:2783]
|
| |
|
|
|
| |
:class:`.Column` object would not be propagated. Also in 0.8.3, 0.7.11.
[ticket:2784]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
form of a some expressions when referring to the ``.c`` collection
on a ``select()`` construct, but the ``str()`` form isn't available
since the element relies on dialect-specific compilation constructs,
notably the ``__getitem__()`` operator as used with a Postgresql
``ARRAY`` element. The fix also adds a new exception class
:class:`.UnsupportedCompilationError` which is raised in those cases
where a compiler is asked to compile something it doesn't know
how to.
[ticket:2780]
|
| |
|
|
|
|
|
|
|
|
| |
:meth:`.Insert.from_select`. Given a list of columns and
a selectable, renders ``INSERT INTO (table) (columns) SELECT ..``.
While this feature is highlighted as part of 0.9 it is also
backported to 0.8.3. [ticket:722]
- The :func:`.update`, :func:`.insert`, and :func:`.delete` constructs
will now interpret ORM entities as FROM clauses to be operated upon,
in the same way that select() already does.
|
| |
|
|
|
|
|
| |
table is a SELECT with its own bound parameters, where the positioning
of the bound parameters would be reversed versus the statement
itself when using MySQL's special syntax.
[ticket:2768]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- add support for correlations to propagate all the way in; because
correlations require context now, need to make sure a select enclosure
of any level takes effect any number of levels deep.
- fix what we said correlate_except() was supposed to do when we first
released #2668 - "the FROM clause is left intact if the correlated SELECT
is not used in the context of an enclosing SELECT..." - it was not
considering the "existing_froms" collection at all, and prohibited
additional FROMs from being placed in an any() or has().
- add test for multilevel any()
- lots of docs, including glossary entries as we really need to define
"WHERE clause", "columns clause" etc. so that we can explain correlation better
- based on the insight that a SELECT can correlate anything that ultimately
came from an enclosing SELECT that links to this one via WHERE/columns/HAVING/ORDER BY,
have the compiler keep track of the FROM lists that correspond in this way,
link it to the asfrom flag, so that we send to _get_display_froms() the exact
list of candidate FROMs to correlate. no longer need any asfrom logic in the
Select() itself
- preserve 0.8.1's behavior for correlation when no correlate options are given, not
to mention 0.7 and prior's behavior of not propagating implicit correlation more than one level..
this is to reduce surprises/hard-to-debug situations when a user isn't trying
to correlate anything.
Conflicts:
doc/build/changelog/changelog_08.rst
doc/build/changelog/changelog_09.rst
lib/sqlalchemy/sql/compiler.py
|
| |
|
|
|
|
|
|
|
|
|
|
| |
called :attr:`.TypeDecorator.coerce_to_is_types`,
to make it easier to control how comparisons using
``==`` or ``!=`` to ``None`` and boolean types goes
about producing an ``IS`` expression, or a plain
equality expression with a bound parameter.
[ticket:2744]
Conflicts:
doc/build/changelog/changelog_09.rst
|
| |
|
|
|
|
|
| |
with legitimate iterable detection, [ticket:2726]
Conflicts:
doc/build/changelog/changelog_09.rst
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
regards to the True/False constants. An expression like
``col.is_(True)`` will now render ``col IS true``
on the target platform, rather than converting the True/
False constant to an integer bound parameter.
This allows the ``is_()`` operator to work on MySQL when
given True/False constants.
[ticket:2682]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
labeled columns when apply_labels() is used; this mode
produces a SELECT where each column is labeled as in
<tablename>_<columnname>, to remove column name collisions
for a multiple table select. The fix is that if two labels
collide when combined with the table name, i.e.
"foo.bar_id" and "foo_bar.id", anonymous aliasing will be
applied to one of the dupes. This allows the ORM to handle
both columns independently; previously, 0.7
would in some cases silently emit a second SELECT for the
column that was "duped", and in 0.8 an ambiguous column error
would be emitted. The "keys" applied to the .c. collection
of the select() will also be deduped, so that the "column
being replaced" warning will no longer emit for any select()
that specifies use_labels, though the dupe key will be given
an anonymous label which isn't generally user-friendly.
[ticket:2702]
|
| |
|
|
|
|
|
|
|
|
|
| |
subclass could insert the row for the "sub" table
before the parent table, if the two tables had no
ForeignKey constraints set up between them.
Also in 0.7.11. [ticket:2689]
- fix a glitch in the assertsql.CompiledSQL fixture regarding
when a multiparam compiledSQL is used within an AllOf
- add a new utility function randomize_unitofwork() which
does the function of --reversetop
|
| |\ |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
| |
- remove most use of "whereclause" and "from_obj", not done yet,
part of [ticket:2679]
- add links to method chained versions for all Select.append_XYZ()
calls
- add "method chaining" and "generative" to glossary
|
| |
|
|
|
|
|
|
| |
added, which proxies down to the ``.info`` attribute on either
the :class:`.schema.Column` object if directly present, or
the :class:`.MapperProperty` otherwise. The full behavior
is documented and ensured by tests to remain stable.
[ticket:2675]
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
don't exist in the superquery.
|
| |
|
|
|
|
|
|
|
|
| |
attempts to emit SQL on a Session within the after_commit()
handler, where there is not a viable transaction in progress.
[ticket:2662]
- rework how SessionTransaction maintains state, using symbols
instead.
- add lots of notes and cross-linking for session events.
- add a link to :func:`.select()` within :meth:`.FromClause.select`.
|
| |
|
|
|
|
| |
so that it works correctly with the new relationship local/remote
system.
[ticket:1768]
|
| |
|
|
|
|
|
|
| |
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]
|
| | |
|
| |
|
|
|
| |
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]
|
| |
|
|
|
|
| |
INSERT/UPDATE bound parameters that need to be passed, so that
it's more easily identifiable when writing custom bind-handling
code. [ticket:2648]
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |\ |
|