| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
|
| |
would produce a parenthesized expression not accepted by some databases.
[ticket:2754]
|
| |
|
|
|
|
| |
the :func:`.aliased` function. Previously, composite attributes
wouldn't work correctly in comparison operations when aliasing
was applied. Also in 0.8.2. [ticket:2755]
|
| |
|
|
|
|
| |
- version (0.9 for now)
- changelog
- move the test into the test suite so that all dialects can take advantage of it
|
| |
|
|
|
|
| |
"commit-on-return". This is enabled with the rest of pool
"debug" logging.
[ticket:2752]
|
| | |
|
| | |
|
| |
|
|
| |
the bigger issue
|
| | |
|
| |
|
|
| |
- docs docs docs
|
| | |
|
| | |
|
| |
|
|
| |
- use an isinstance() check, concerned a TypeError might be indiscriminate
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scalar values, for comparisons to None to also take into account
the association record itself being non-present, in addition to the
existing test for the scalar endpoint on the association record
being NULL. Previously, comparing ``Cls.scalar == None`` would return
records for which ``Cls.associated`` were present and
``Cls.associated.scalar`` is None, but not rows for which
``Cls.associated`` is non-present. More significantly, the
inverse operation ``Cls.scalar != None`` *would* return ``Cls``
rows for which ``Cls.associated`` was non-present.
Additionally, added a special use case where you
can call ``Cls.scalar.has()`` with no arguments,
when ``Cls.scalar`` is a column-based value - this returns whether or
not ``Cls.associated`` has any rows present, regardless of whether
or not ``Cls.associated.scalar`` is NULL or not.
[ticket:2751]
|
| |
|
|
|
|
|
|
|
|
|
| |
fetched when joining/joinedloading across a many-to-many
relationship to a single-table-inheriting
subclass with a specific discriminator value, due to "secondary"
rows that would come back. The "secondary" and right-side
tables are now inner joined inside of parenthesis for all
ORM joins on many-to-many relationships so that the left->right
join can accurately filtered.
[ticket:2369]
|
| |
|
|
|
|
|
| |
a CAST call that was added in 0.8.1 to help with driver issues,
which apparently is not compatible on 2000.
The CAST remains in place for SQL Server 2005 and greater.
[ticket:2747]
|
| |
|
|
|
|
|
|
| |
:class:`.ForeignKeyConstraint` will not render the ``DEFERRABLE`` keyword
on the MySQL dialect. For a long time we left this in place because
a non-deferrable foreign key would act very differently than a deferrable
one, but some environments just disable FKs on MySQL, so we'll be less
opinionated here. [ticket:2721]
|
| |
|
|
|
| |
when ``clear()`` was called.
[ticket:2730]
|
| |
|
|
|
|
|
|
| |
foreign key paths to a table "B", to that table "B", would fail
to produce the "ambiguous join condition" error that would be
reported if you join table "A" directly to "B"; it would instead
produce a join condition with multiple criteria.
[ticket:2738]
|
| |
|
|
|
|
| |
schema as well as a local schema could produce wrong results
in the case where both schemas had a table of the same name.
[ticket:2728]
|
| |
|
|
| |
with legitimate iterable detection, [ticket:2726]
|
| |
|
|
| |
- inline the label check
|
| |
|
|
|
| |
- restore the rollback cleanup handler, pg8000 is mostly obsolete
as a dialect and the firebird drivers need it
|
| | |
|
| |
|
|
|
|
|
| |
evaluation invoked by :meth:`.Query.update` and :meth:`.Query.delete`
would hit upon unsupported ``True`` and ``False`` symbols
which now appear due to the usage of ``IS``.
[ticket:2737]
|
| |
|
|
|
|
| |
method has been turned off. The specific behavior is now
availble via a new method :class:`.Query.select_entity_from`.
[ticket:2736]
|
| | |
|
| |
|
|
| |
- changelog, migration doc
|
| | |
|
| |
|
|
|
| |
of SQL cache keys wasn't applying deduping labels to the
statement the same way :class:`.Query` normally does.
|
| |
|
|
|
|
| |
being sent to :func:`.create_engine` would fail in some cases,
such as with the Sybase dialect.
[ticket:2732]
|
| |
|
|
|
|
| |
"true" to render, added logic to convert this to 1/0
for SQL server.
[ticket:2682]
|
| |
|
|
|
|
|
|
| |
made the check for recursion overflow in self-referential
eager joining too loose, missing a particular circumstance
where a subclass had lazy="joined" or "subquery" configured
and the load was a "with_polymorphic" against the base.
[ticket:2481]
|
| |
|
|
|
|
|
| |
of :meth:`.Session.begin_nested` would fail to correctly
roll back the transaction when a flush error occurred, instead
raising its own exception while leaving the session still
pending a rollback. [ticket:2718]
|
| |
|
|
|
| |
on the apparent string message sent in the exception; tested
against mysqlconnector 1.0.9.
|
| | |
|
| |
|
|
|
|
|
| |
that the "id" passed from the pickler is turned into a string
to prevent against bytes being parsed on Py3K, as well as that
``relationship()`` and ``orm.join()`` constructs are now properly
serialized. [ticket:2698] and some other observed issues.
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
mapped objects, such that if the reference to the object
were lost when the object was pickled, we don't
erroneously try to set up _sa_instance_state - fixes
a NoneType error.
|
| | |
| |
| |
| | |
false positives for SQL statements containing certain text
|
| | |
| |
| |
| |
| |
| |
| |
| | |
to check for all the various "disconnect" messages within
the full exception hierarchy. Specifically the
"closed the connection unexpectedly" message has now been
seen in at least three different exception types.
[ticket:2712]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]
|
| | |
| |
| |
| | |
unconditonally instead so that it works in all cases.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
input types of sets, generators, etc. but only when a dimension
is specified for the ARRAY; otherwise, the dialect
needs to peek inside of "arr[0]" to guess how many
dimensions are in use. If this occurs with a non
list/tuple type, the error message is now informative
and directs to specify a dimension for the ARRAY.
[ticket:2681]
|
| | |
| |
| |
| | |
- just do a fetchone() here, no need for len() etc.
|