| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
| |
additional test
that is much more specific to #1326
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
:meth:`.Session.get_bind` method when calling upon
:meth:`.Query.count`, :meth:`.Query.update`, :meth:`.Query.delete`,
as well as queries against mapped columns,
:obj:`.column_property` objects, and SQL functions and expressions
derived from mapped columns. This allows sessions that rely upon
either customized :meth:`.Session.get_bind` schemes or "bound" metadata
to work in all relevant cases.
fixes #3227 fixes #3242 fixes #1326
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
sane multi rowcount (e.g. pyodbc) would fail on multirow update. add
a test that mocks this breakage into plain dialects
|
| | |
|
| |
|
|
| |
- start writing docs
|
| |\
| |
| |
| |
| | |
Conflicts:
lib/sqlalchemy/orm/persistence.py
|
| | |
| |
| |
| | |
Output in the error message the table name and the column name.
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
Output in the error message the table name and the column name.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
names in the given dictionary of values into mapped attribute names
against the mapped class being updated. Previously, string names
were taken in directly and passed to the core update statement without
any means to resolve against the mapped entity. Support for synonyms
and hybrid attributes as the subject attributes of
:meth:`.Query.update` are also supported.
fixes #3228
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| | |
times spent start getting barely different...
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
N occurrences of a parameterized string. This allows parameterized
warnings that can refer to their arguments to be delivered a fixed
number of times until allowing Python warning filters to squelch them,
and prevents memory from growing unbounded within Python's
warning registries.
fixes #3178
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
_collect_update_commands and _collect_delete_commands
|
| |\ \
| |/ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
| |
| |
| |
| | |
Conflicts:
lib/sqlalchemy/orm/mapper.py
lib/sqlalchemy/orm/persistence.py
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
setting up given values vs. defaults. again trying to shoot for
making this of more general use
|
| | |
| |
| |
| |
| |
| | |
narrow down argument lists and generator items for each function
down to just what each function needs. This will help for them
to be of more multipurpose use for bulk operations
|
| | |
| |
| |
| |
| |
| | |
we only call upon the history API fully for primary key columns.
We also now skip the whole step of looking at PK columns and using
any history at all if no net changes are detected on the object.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
``@validates`` would have events triggered within the flush process,
when those columns were the targets of a "fetch and populate"
operation, such as an autoincremented primary key, a Python side
default, or a server-side default "eagerly" fetched via RETURNING.
fixes #3167
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
to be more than twice as fast now (.039 vs. .091); bulk_insert()
and bulk_update() do their own collection but now both call into
_emit_insert_statements() / _emit_update_statements(); the approach
seems to have no impact on insert speed, still .85 for the
insert test
|
| | |
| |
| |
| | |
methods
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
into more performant executemany() call, similarly to how INSERT
statements can be batched; this will be invoked within flush
to the degree that subsequent UPDATE statements for the
same mapping and table involve the identical columns within the
VALUES clause, as well as that no VALUES-level SQL expressions
are embedded.
- some other inlinings within persistence.py
|
| | |
|
| |
|
|
| |
sqlalchemy/orm, sqlalchemy/event, sqlalchemy/testing
|
| |
|
|
| |
to get all flake8 passing
|
| |
|
|
|
|
|
| |
updates, and needs to be set to `synchronize_session=False` or
`synchronize_session='fetch'`; this now raises an exception, with a
message to change the synchronize setting. This will be only a warning
in 0.9.7. fixes #3117
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
implicitly initialized to None via first access; this action,
which has always resulted in a population of the attribute,
now emits an attribute event just like any other attribute set
operation and generates the same kind of history as one. Additionally,
many mapper internal operations will no longer implicitly generate
these "None" values when various never-set attributes are checked.
These are subtle behavioral fixes to attribute mechanics which provide
a better solution to the problem of :ticket:`3060`, which also
involves recognition of attributes explicitly set to ``None``
vs. attributes that were never set.
fixes #3061
|
| |
|
|
|
|
|
|
|
|
|
| |
scenario, where an INSERT/DELETE can be turned into an UPDATE.
In this situation, a many-to-one relationship set to None, or
in some cases a scalar attribute set to None, may not be detected
as a net change in value, and therefore the UPDATE would not reset
what was on the previous row. This is due to some as-yet
unresovled side effects of the way attribute history works in terms
of implicitly assuming None isn't really a "change" for a previously
un-set attribute. See also :ticket:`3061`. fixes #3060
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to True, indicates that a series of DELETE statements should confirm
that the cursor rowcount matches the number of primary keys that should
have matched; this behavior had been taken off in most cases
(except when version_id is used) to support the unusual edge case of
self-referential ON DELETE CASCADE; to accomodate this, the message
is now just a warning, not an exception, and the flag can be used
to indicate a mapping that expects self-refererntial cascaded
deletes of this nature. See also :ticket:`2403` for background on the
original change. re: #2403 fix #3007
|