| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
| |
Arguments such as cipher, kdf_iter, cipher_page_size and
cipher_use_hmac may (always?) require quotes within the
PRAGMA directive.
Change-Id: I2c808f34e1c44f0593b72b304e170e4af0a6035a
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/319
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed regression caused by the fix in :ticket:`3807` (version 1.1.0)
where we ensured that the tablename was qualified in the WHERE clause
of the DO UPDATE portion of PostgreSQL's ON CONFLICT, however you
*cannot* put the table name in the WHERE clause in the actual ON
CONFLICT itself. This was an incorrect assumption, so that portion
of the change in :ticket:`3807` is rolled back.
Change-Id: I442d8629496a8e405b54711cfcf487761810ae8a
Fixes: #3846
Fixes: #3807
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Options like uselist and backref can be determined from
within _register_attribute based on parent_property
given; move this logic inside so that individual strategies
have less responsibility. Also don't require that
_register_attribute consider the "strategy" itself
at all; it would be better if we could no longer require
that Joined/Subquery/etc loaders call upon the "lazy" strategy
in order to initialize attribute instrumentation and
this could be done more generically.
Fixes long-standing bug where the "noload" relationship loading
strategy would cause backrefs and/or back_populates options to be
ignored. There is concern that some application that uses
"noload" might be surprised at a back-populating attribute
appearing suddenly, which may have side effects. However,
"noload" itself must be extremely seldom used since as a
strategy, it already disables loading, population of attributes
is the only behavior that is even supported, so that this issue has existed
for at least through 0.7 four years ago without ever being
reported indicates extremely low use of this option.
Change-Id: Icffb9c83ac5782b76ce882ed1df4361a1efbfba3
Fixes: #3845
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
MySQL's native ENUM type supports any non-valid value being sent, and
in response will return a blank string. A hardcoded rule to check for
"is returning the blank string" has been added to the MySQL
implementation for ENUM so that this blank string is returned to the
application rather than being rejected as a non-valid value. Note that
if your MySQL enum is linking values to objects, you still get the
blank string back.
Change-Id: I61f85c20293a48b0c11a31f2a19f6756c206bd20
Fixes: #3841
|
| |
|
|
| |
Change-Id: I6545ebfeeee103cac133d0b8270a860cba2d2996
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed regression caused by :ticket:`2677` whereby calling
:meth:`.Session.delete` on an object that was already flushed as
deleted in that session would fail to set up the object in the
identity map (or reject the object), causing flush errors as the
object were in a state not accommodated by the unit of work.
The pre-1.1 behavior in this case has been restored, which is that
the object is put back into the identity map so that the DELETE
statement will be attempted again, which emits a warning that the number
of expected rows was not matched (unless the row were restored outside
of the session).
Change-Id: I9a8871f82cb1ebe67a7ad54d888d5ee835a9a40a
Fixes: #3839
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
_ColumnEntity didn't seem to have .mapper present, which
due to the way _mapper_zero() worked didn't tend to come
across it. With :ticket:`3608` _mapper_zero() has
been simplified so make sure this is now present.
Also ensure that _select_from_entity is an entity and
not a mapped class, though this does not seem to matter
at the moment.
Fixes: #3836
Change-Id: Id6dae8e700269b97de3b01562edee95ac1e01f80
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Postgresql table reflection will ensure that the
:paramref:`.Column.autoincrement` flag is set to False when reflecting
a primary key column that is not of an :class:`.Integer` datatype,
even if the default is related to an integer-generating sequence.
This can happen if a column is created as SERIAL and the datatype
is changed. The autoincrement flag can only be True if the datatype
is of integer affinity in the 1.1 series.
This bug is related to a test failure in downstream sqlalchemy_migrate.
Change-Id: I40260e47e1927a1ac940538408983c943bbdba28
Fixes: #3835
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed bug involving new value translation and validation feature
in :class:`.Enum` whereby using the enum object in a string
concatenation would maintain the :class:`.Enum` type as the type
of the expression overall, producing missing lookups. A string
concatenation against an :class:`.Enum`-typed column now uses
:class:`.String` as the datatype of the expression itself.
Change-Id: Id402054e3ef008e0250c740dbb7e1c80f339fe78
Fixes: #3833
|
| |/
|
|
|
| |
Change-Id: I27251c262f919df1b084cbb08759f672f05cd3f7
Fixes: #3834
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure TypeDecorator delegates _set_parent_with_dispatch as well as
_set_parent to itself as well as its impl, as the TypeDecorator
class itself may have an active SchemaType implementation as well.
Fixed regression which occurred as a side effect of :ticket:`2919`,
which in the less typical case of a user-defined
:class:`.TypeDecorator` that was also itself an instance of
:class:`.SchemaType` (rather than the implementation being such)
would cause the column attachment events to be skipped for the
type itself.
Change-Id: I0afb498fd91ab7d948e4439e7323a89eafcce0bc
Fixes: #3832
|
| |
|
|
| |
Change-Id: I283e52a7a63ec4f7a285aba1b41627f11b7ad41b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change to "evaluates none" datatypes in the ORM was
not fully described in the migration notes, missing the
key behavioral change that a column which is missing a default
entirely will not receive a value for a missing JSON column now.
The issue here touched upon a revisit of the assumptions
in [ticket:3514], but overall the old behavior "worked" mostly
because the ORM wants to explicitly render NULL into an INSERT
for column values that are missing, which itself is a legacy
behavior which should be considered for possible removal in
a future major release. Given that "missing ORM value + no
column default set up == dont put it in the INSERT" would be
the most intuitive behavior, the move in [ticket:3514] represents
a step in this direction.
Change-Id: I454d5bb0773bd73d9864925dcc47f1f0810e33ba
Fixes: #3830
|
| | |
|
| |
|
|
| |
Change-Id: I49df318c77f9f539541e7edea857bd256aca2844
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Changed the naming convention used when generating bound parameters
for a multi-VALUES insert statement, so that the numbered parameter
names don't conflict with the anonymized parameters of a WHERE clause,
as is now common in a PostgreSQL ON CONFLICT construct.
Change-Id: I3188d100fe4d322a47d344d6a63d3e40b915f228
Fixes: #3828
|
| |/
|
|
|
|
|
|
|
| |
The context is unclear if "fundamental" refers to the object's
role within a SELECT composition or within the class hierarchy
of ClauseElement classes.
Change-Id: I10bbf324fc09034cc27398867b7eca6b6f127abe
Fixes: #3793
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Boolean and Enum types both place SchemaType second in the
inheritance hierarchy. In the case of Enum, this works
out that the copy() method is called from the base TypeEngine
which fails to transfer _create_events. The test suite
doesn't seem to work with the inhertance hierarchy set up like
this as the event listeners don't work out, the _on_metadata_create
and _on_table_create hooks cause the production of an adapted type
which then adds event listeners that cause deque changed while
iteration. It's not clear why Enum /Boolean don't have this problem.
But in any case it seems like the class mechanics for these types
remains fragile and would benefit from yet another refactor someday.
Change-Id: Ib641a5d2321b00f58bbe98dd0c5e789374db32b2
Fixes: #3827
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a new variant to the "isnew" state within entity loading
for isnew=False, but the load path is new. This is to address
the use case of an entity appearing in multiple places in
the row in a more generalized way than the fixes in [ticket:3431],
[ticket:3811] in that loading.py will be able to tell the
populator that this row is not "isnew" but is a "new" path
for the entity. For the moment, the new information is only
being applied to the use of "quick" populators so that
simple column loads can take place on top of a deferred loader
from elsewhere in the row.
As part of this change, state.load_path() will now always
be populated with the "path" that was in effect when this state
was originally loaded, which for multi-path loads of the
same entity is still non-deterministic. Ideally there'd be some
kind of "here's all the paths that loaded this state and how"
type of data structure though it's not clear if that could be
done while maintaining performance.
Fixes: #3822
Change-Id: Ib915365353dfcca09e15c24001a8581113b97d5e
|
| |
|
|
|
|
|
|
|
| |
Discovered during testing for [ticket:3822], the rule added
for [ticket:1495] will fail if the source object has propagated
options set up, which add elements to query._current_path.
Fixes: #3824
Change-Id: I3d96c96fee5f9b247f739d2136d18681ac61f2fe
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The newly added wrap_callable() function assumes __module__
is present when this is not the case for objects such as
functools.partial.
Change-Id: Ia226260e9a65419e26d5c1f7187512f7fd4bb7c1
Fixes: #3823
|
| |/
|
|
|
| |
The second 'if' condition was never called because the original
condition always returns.
|
| |
|
|
| |
Change-Id: I50daaee2645dd8aa2ee7217f4065589492ed0b7d
|
| |
|
|
| |
Change-Id: I4a7ef54bec3891821954061a9b4ed19d398989f3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While reviewing a change that created a new table, the
primary_key column value was set to True but nullable was not
explicitly set, which led to some confusion over the default
behavior for the nullable column value when setting a primary_key.
Looking at the docs it's not clear, but the code shows that if
nullable is not specified, then nullable = not primary_key, so
nullable defaults to False when primary_key is True.
This patch adds a simple clarification to the docs so people
don't have to check the code.
Change-Id: I8553339d56fbae11370c7c6af6d8d4723163be1c
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/312
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Users are complaining that IntegrityError is no longer
raised.
Change-Id: I0855d5b7a98d4338f0910501b6e6d404ba33634d
Fixes: #3216
|
| |
|
|
|
| |
Change-Id: Ide9e916d02fbbef549aa2838d1402c2b091e701d
Fixes: #3820
|
| |
|
|
| |
Change-Id: I569a03a6e86aa096be6744ecb479fe8485f7def6
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Compiler can now set up execution options and additionally
will propagate autocommit from embedded CTEs.
Change-Id: I19db7b8fe4d84549ea95342e8d2040189fed1bbe
Fixes: #3805
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ORM attributes can now be assigned any object that is has a
``__clause_element__()`` attribute, which will result in inline
SQL the way any :class:`.ClauseElement` class does. This covers other
mapped attributes not otherwise transformed by further expression
constructs.
As part of this, it was considered that we could add
__clause_element__() to ClauseElement, however this causes endless loops
in a "while" pattern and this pattern has been identified in third
party libraries. Add a test to ensure we never make that change.
Change-Id: I9e15b3f1c4883fd3909acbf7dc81d034c6e3ce1d
Fixes: #3802
|
| |
|
|
|
|
|
|
|
|
| |
An adjustment to ON CONFLICT such that the "inserted_primary_key"
logic is able to accommodate the case where there's no INSERT or
UPDATE and there's no net change. The value comes out as None
in this case, rather than failing on an exception.
Change-Id: I0794e95c3ca262cb1ab2387167d96b8984225fce
Fixes: #3813
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The "raise_on_sql" option differentiates from "raise" in that
firing a lazy loader is OK as long as it does a simple
get from identity map. Whereas "raise" is more useful
for the case that objects are to be detached.
As part of this, refactors the strategy initiation logic
a bit so that a LoaderStrategy itself knows what "key" was used
to create it, thus allowing variants of a single strategy
based on what the "lazy" argument is. To achieve this we
have to also get rid of _get_strategy_by_cls().
Everything here is internal with the one exception of an apparently
undocumented, but not underscored, "strategy_class" key
on relationship(). Though it's not clear what
"strategy_class" accomplishes; at this point the strategy
system is extensible using Property.strategy_for().
Fixes: #3812
Change-Id: I812ad878ea5cf764e15f6f71cb39eee78a645d88
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The change in #3431 still checks that the instance() is
non-None, deferring to other loading schemes if it is.
These columns are dedicated towards the entity however, so if the value
is None, we should set it. If it conflicts, we are detecting that
in any case.
Change-Id: I223768e2898e843f953e910da1f9564b137d95e4
Fixes: #3811
|