| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
features that other objects like :class:`.Index` now do, that
the column expression may be specified as an arbitrary SQL
expression such as :obj:`.cast` or :obj:`.text`.
fixes #3454
|
| |
|
|
|
|
|
|
|
|
|
|
| |
object would fail to accommodate the labeled SQL expression
in all cases, such that any SQL operation that made use of
:meth:`.Label.self_group` would use the original unadapted
expression. One effect of this would be that an ORM :func:`.aliased`
construct would not fully accommodate attributes mapped by
:obj:`.column_property`, such that the un-aliased table could
leak out when the property were used in some kinds of SQL
comparisons.
fixes #3445
|
| |
|
|
|
|
|
|
|
|
|
| |
inside of :meth:`.Insert.from_select`. This behavior worked
accidentally up until 0.9.9, when it no longer worked due to
unrelated changes as part of :ticket:`3248`. Note that this
is the rendering of the WITH clause after the INSERT, before the
SELECT; the full functionality of CTEs rendered at the top
level of INSERT, UPDATE, DELETE is a new feature targeted for a
later release.
fixes #3418
|
| |
|
|
|
|
|
|
|
|
|
| |
:ticket:`3341` where in the unusual case of a constraint that refers
to a mixture of :class:`.Column` objects and string column names
at the same time, the auto-attach-on-column-attach logic will be
skipped; for the constraint to be auto-attached in this case,
all columns must be assembled on the target table up front.
Added a new section to the migration document regarding the
original feature as well as this change.
fixes #3411
|
| |
|
|
|
|
| |
which is now consumed by Alembic migrations as of 0.7.6. User-defined
types can implement this method to assist in the comparison of
a type against one reflected from the database.
|
| |
|
|
|
|
|
|
|
|
| |
a label that overlapped another label that is not truncated; this
because the length threshhold for truncation was greater than
the portion of the label that remains after truncation. These
two values have now been made the same; label_length - 6.
The effect here is that shorter column labels will be "truncated"
where they would not have been truncated before.
fixes #3396
|
| |
|
|
|
|
|
|
| |
now skip textual label references when copying ORDER BY elements
to the joined-eager-load subquery, as we can't know that these
expressions are compatible with this placement; either because
they are meant for text(), or because they refer to label names
already stated and aren't bound to a table. fixes #3392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
passed as a keyword argument to the :meth:`.DDLEvents.before_create`,
:meth:`.DDLEvents.after_create`, :meth:`.DDLEvents.before_drop`, and
:meth:`.DDLEvents.after_drop` events would no longer be a list
of tables, but instead a list of tuples which contained a second
entry with foreign keys to be added or dropped. As the ``tables``
collection, while documented as not necessarily stable, has come
to be relied upon, this change is considered a regression.
Additionally, in some cases for "drop", this collection would
be an iterator that would cause the operation to fail if
prematurely iterated. The collection is now a list of table
objects in all cases and test coverage for the format of this
collection is now added.
fixes #3391
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(hence becoming two regressions); reports that
SELECT statements would GROUP BY a label name and fail was misconstrued
that certain backends such as SQL Server should not be emitting
ORDER BY or GROUP BY on a simple label name at all; when in fact,
we had forgotten that 0.9 was already emitting ORDER BY on a simple
label name for all backends, as described in :ref:`migration_1068`,
as 1.0 had rewritten this logic as part of :ticket:`2992`.
In 1.0.2, the bug is fixed both that SQL Server, Firebird and others
will again emit ORDER BY on a simple label name when passed a
:class:`.Label` construct that is expressed in the columns clause,
and no backend will emit GROUP BY on a simple label name in this case,
as even Postgresql can't reliably do GROUP BY on a simple name
in every case.
fixes #3338, fixes #3385
|
| |
|
|
|
|
| |
with Firebird, so that the values are again rendered inline when
this is selected. Related to :ticket:`3034`.
fixes #3381
|
| |
|
|
|
|
|
|
|
|
| |
applying any topological sort to tables on SQLite. See the
changelog for details, but we now continue to sort
tables for SQLite on DROP, prohibit the sort from considering
alter, and only warn if we encounter an unresolvable cycle, in
which case, then we forego the ordering. use_alter as always
is used to break such a cycle.
fixes #3378
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assign the proper result type of Boolean to the result mapping, and
instead would leak column types from within the query into the
result map. This issue exists in 0.9 and earlier as well, however
has less of an impact in those versions. In 1.0, due to #918
this becomes a regression in that we now rely upon the result mapping
to be very accurate, else we can assign result-type processors to
the wrong column. In all versions, this issue also has the effect
that a simple EXISTS will not apply the Boolean type handler, leading
to simple 1/0 values for backends without native boolean instead of
True/False. The fix includes that an EXISTS columns argument
will be anon-labeled like other column expressions; a similar fix is
implemented for pure-boolean expressions like ``not_(True())``.
fixes #3372
|
| |
|
|
|
|
|
|
| |
convention would not properly work with pickle. The attribute was
skipped leading to inconsistencies and failures if the unpickled
:class:`.MetaData` object were used to base additional tables
from.
fixes #3362
|
| |
|
|
|
|
|
| |
for an insert from select are the string names, and not
the Column objects. The MSSQL dialect in particular relies upon
checking for these keys in params to know if identity insert
should be on. references #3360
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| | |
agaisnt -> against
'a Alias' -> 'an Alias'
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
and :class:`.CheckConstraint` has been further enhanced such that
when the constraint is associated with non-table-bound :class:`.Column`
objects, the constraint will set up event listeners with the
columns themselves such that the constraint auto attaches at the
same time the columns are associated with the table. This in particular
helps in some edge cases in declarative but is also of general use.
fixes #3341
|
| | |
| |
| |
| |
| |
| |
| |
| | |
a label that was anonymous, then labeled again with a name, would
fail to be locatable via a textual label. This situation occurs
naturally when a mapped :func:`.column_property` is given an
explicit label in a query.
fixes #3340
|
| | |
| |
| |
| |
| |
| |
| |
| | |
the string label placed in the order_by() or group_by() of a statement
would place higher priority on the name as found
inside the FROM clause instead of a more locally available name
inside the columns clause.
fixes #3335
|
| | |
| |
| |
| | |
since they've apparently added something for it
|
| | |
| |
| |
| |
| | |
unfortunately Sphinx refuses to work correctly for the columns
attribute so we just add a lame message to contains_column().
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DROP TYPE instruction when a plain ``table.drop()`` is called,
assuming the object is not associated directly with a
:class:`.MetaData` object. In order to accomodate the use case of
an enumerated type shared between multiple tables, the type should
be associated directly with the :class:`.MetaData` object; in this
case the type will only be created at the metadata level, or if
created directly. The rules for create/drop of
Postgresql enumerated types have been highly reworked in general.
fixes #3319
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
for the slots-based __getattr__ thing getting hit
|
| | |
| |
| |
| |
| | |
- replace force_result_map with a mini-API for nested result sets, add
coverage
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The "wrapping" employed by the mssql and oracle dialects using the
"iswrapper" argument was not being used intelligently by the compiler,
and the result map was being written incorrectly, using
*more* columns in the result map than were actually returned by
the statement, due to "row number" columns that are inside the
subquery. The compiler now writes out result map on the
"top level" select in all cases
fully, and for the mssql/oracle wrapping case extracts out
the "proxied" columns in a second step, which only includes
those columns that are proxied outwards to the top level.
This change might have implications for 3rd party dialects that
might be imitating oracle's approach. They can safely continue
to use the "iswrapper" kw which is now ignored, but they may
need to also add the _select_wraps argument as well.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
such that they are matched to the received result set positionally,
rather than by name. Originally, this was seen as a way to handle
cases where we had columns returned with difficult-to-predict names,
though in modern use that issue has been overcome by anonymous
labeling. In this version, the approach basically reduces function
call count per-result by a few dozen calls, or more for larger
sets of result columns. The approach still degrades into a modern
version of the old approach if textual elements modify the result
map, or if any discrepancy in size exists between
the compiled set of columns versus what was received, so there's no
issue for partially or fully textual compilation scenarios where these
lists might not line up. fixes #918
- callcounts still need to be adjusted down for this so zoomark
tests won't pass at the moment
|
| |
|
|
|
|
|
| |
when using the :paramref:`.Column.server_default` parameter, will
now be rendered using the "inline" compiler, so that they are rendered
as-is, rather than as bound parameters.
fixes #3087
|
| |
|
|
|
|
|
|
|
|
| |
conventions that include the token ``%(column_0_name)s``; the
constraint expression is scanned for columns. Additionally,
naming conventions for check constraints that don't include the
``%(constraint_name)s`` token will now work for :class:`.SchemaType`-
generated constraints, such as those of :class:`.Boolean` and
:class:`.Enum`; this stopped working in 0.9.7 due to :ticket:`3067`.
fixes #3299
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the logic used to link a :class:`.ForeignKey` to its parent could fail
when the foreign key used "link_to_name=True" in conjunction with
a target :class:`.Table` that would not receive its parent column until
later, such as within a reflection + "useexisting" scenario,
if the target column in fact had a key value different from its name,
as would occur in reflection if column reflect events were used to
alter the .key of reflected :class:`.Column` objects so that the
link_to_name becomes significant. Also repaired support for column
type via FK transmission in a similar way when target columns had a
different key and were referenced using link_to_name.
fixes #3298
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
now be constructed such that the visit methods receive an indication
of the owning expression object, if any. Any visit method that
accepts keyword arguments (e.g. ``**kw``) will in most cases
receive a keyword argument ``type_expression``, referring to the
expression object that the type is contained within. For columns
in DDL, the dialect's compiler class may need to alter its
``get_column_specification()`` method to support this as well.
The ``UserDefinedType.get_col_spec()`` method will also receive
``type_expression`` if it provides ``**kw`` in its argument
signature.
fixes #3074
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
repaired to work more usefully with tables that have Python-
side default values and/or functions, as well as server-side
defaults. The feature will now work with a dialect that uses
"positional" parameters; a Python callable will also be
invoked individually for each row just as is the case with an
"executemany" style invocation; a server- side default column
will no longer implicitly receive the value explicitly
specified for the first row, instead refusing to invoke
without an explicit value. fixes #3288
|
| | |
| |
| |
| | |
Needed for alembic autogenerate rendering.
|
| | |
| |
| |
| |
| | |
for memoization on a class that uses slots.
- apply many more __slots__. mem use for nova now at 46% savings
|
| | |
| |
| |
| | |
get PG stuff working
|
| | | |
|
| | |
| |
| |
| |
| | |
size of the many per-column objects we're hitting, but somehow the overall memory is
hardly being reduced at all in initial testing
|
| | |
| |
| |
| |
| | |
- test_schema_2 is only on PG and doesn't need a drop all, omit this for now
- py3k has exception.args[0], not message
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
sort_tables_and_constraints function.
- The DDL generation system of :meth:`.MetaData.create_all`
and :meth:`.Metadata.drop_all` has been enhanced to in most
cases automatically handle the case of mutually dependent
foreign key constraints; the need for the
:paramref:`.ForeignKeyConstraint.use_alter` flag is greatly
reduced. The system also works for constraints which aren't given
a name up front; only in the case of DROP is a name required for
at least one of the constraints involved in the cycle.
fixes #3282
|
| | |
| |
| |
| |
| | |
to complement the :attr:`.Table.foreign_keys` collection,
as well as :attr:`.ForeignKeyConstraint.referred_table`.
|
