History log of /sqlalchemy/test/profiles.txt (Results 1 - 25 of 159)
Revision Date Author Comments
# aa026c30 30-Oct.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

2.0 removals: LegacyRow, connectionless execution, close_with_result

in order to remove LegacyRow / LegacyResult, we have
to also lose close_with_result, which connectionless
executi

2.0 removals: LegacyRow, connectionless execution, close_with_result

in order to remove LegacyRow / LegacyResult, we have
to also lose close_with_result, which connectionless
execution relies upon.

also includes a new profiles.txt file that's all against
py310, as that's what CI is on now. some result counts
changed by one function call which was enough to fail the
low-count result tests.

Replaces Connectable as the common interface between
Connection and Engine with EngineEventsTarget. Engine
is no longer Connectable. Connection and MockConnection
still are.

References: #7257
Change-Id: Iad5eba0313836d347e65490349a22b061356896a

show more ...


# 95870c95 02-Sep.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

turn off deduping for col expressions

Fixed ORM issue where column expressions passed to ``query()`` or
ORM-enabled ``select()`` would be deduplicated on the identity of the
object,

turn off deduping for col expressions

Fixed ORM issue where column expressions passed to ``query()`` or
ORM-enabled ``select()`` would be deduplicated on the identity of the
object, such as a phrase like ``select(A.id, null(), null())`` would
produce only one "NULL" expression, which previously was not the case in
1.3. However, the change also allows for ORM expressions to render as given
as well, such as ``select(A.data, A.data)`` will produce a result row with
two columns.

Fixes: #6979
Change-Id: I4dd59d4c7b1baa711b686379eb959f87c44841c4

show more ...


# b09dbcf1 18-Aug.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

bump profiles a bit

the change from lambdas in loader strategies as well
as the repair to caching for the Bundle construct has caused
a slight callcount bump.

Change-Id: I0b

bump profiles a bit

the change from lambdas in loader strategies as well
as the repair to caching for the Bundle construct has caused
a slight callcount bump.

Change-Id: I0b160c4a71efdb716f15ac3c128a8addbe10850d

show more ...


# b9874653 15-Aug.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

fix linter JOIN logic; fix PostgreSQL ARRAY op comparison

Adjusted the "from linter" warning feature to accommodate for a chain of
joins more than one level deep where the ON clauses don

fix linter JOIN logic; fix PostgreSQL ARRAY op comparison

Adjusted the "from linter" warning feature to accommodate for a chain of
joins more than one level deep where the ON clauses don't explicitly match
up the targets, such as an expression such as "ON TRUE". This mode of use
is intended to cancel the cartesian product warning simply by the fact that
there's a JOIN from "a to b", which was not working for the case where the
chain of joins had more than one element.

this incurs a bit more compiler overhead that comes out in profiling
but is not extensive.

Added the "is_comparison" flag to the PostgreSQL "overlaps",
"contained_by", "contains" operators, so that they work in relevant ORM
contexts as well as in conjunction with the "from linter" feature.

Fixes: #6886
Change-Id: I078dc3fe6d4f7871ffe4ebac3e71e62f3f213d12

show more ...


# 707e5d70 06-Jul.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

labeling refactor

To service #6718 and #6710, the system by which columns are
given labels in a SELECT statement as well as the system that
gives them keys in a .c or .selected_colum

labeling refactor

To service #6718 and #6710, the system by which columns are
given labels in a SELECT statement as well as the system that
gives them keys in a .c or .selected_columns collection have
been refactored to provide a single source of truth for
both, in constrast to the previous approach that included
similar logic repeated in slightly different ways.

Main ideas:

1. ColumnElement attributes ._label, ._anon_label, ._key_label
are renamed to include the letters "tq", meaning
"table-qualified" - these labels are only used when rendering
a SELECT that has LABEL_STYLE_TABLENAME_PLUS_COL for its
label style; as this label style is primarily legacy, the
"tq" names should be isolated so that in a 2.0 style application
these aren't being used at all

2. The means by which the "labels" and "proxy keys" for the elements
of a SELECT has been centralized to a single source of truth;
previously, the three of _generate_columns_plus_names,
_generate_fromclause_column_proxies, and _column_naming_convention
all had duplicated rules between them, as well as that there
were a little bit of labeling rules in compiler._label_select_column
as well; by this we mean that the various "anon_label" "anon_key"
methods on ColumnElement were called by all four of these methods,
where there were many cases where it was necessary that one method
comes up with the same answer as another of the methods. This
has all been centralized into _generate_columns_plus_names
for all the names except the "proxy key", which is generated
by _column_naming_convention.

3. compiler._label_select_column has been rewritten to both not make
any naming decisions nor any "proxy key" decisions, only whether
to label or not to label; the _generate_columns_plus_names method
gives it the information, where the proxy keys come from
_column_naming_convention; previously, these proxy keys were matched
based on restatement of similar (but not really the same) logic in
two places. The heuristics of "whether to label or not to label"
are also reorganized to be much easier to read and understand.

4. a new method compiler._label_returning_column is added for dialects
to use in their "generate returning columns" methods. A
github search reveals a small number of third party dialects also
doing this using the prior _label_select_column method so we
try to make sure _label_select_column continues to work the
exact same way for that specific use case; for the "SELECT" use
case it now needs

5. After some attempts to do it different ways, for the case where
_proxy_key is giving us some kind of anon label, we are hard
changing it to "_no_label" right now, as there's not currently
a way to fully match anonymized labels from stmt.c or
stmt.selected_columns to what will be in the result map. The
idea of "_no_label" is to encourage the user to use label('name')
for columns they want to be able to target by string name that
don't have a natural name.

Change-Id: I7a92a66f3a7e459ccf32587ac0a3c306650daf11

show more ...


# 5b3e887f 15-Jun.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

memoize current options and joins w with_entities/with_only_cols

Fixed further regressions in the same area as that of :ticket:`6052` where
loader options as well as invocations of metho

memoize current options and joins w with_entities/with_only_cols

Fixed further regressions in the same area as that of :ticket:`6052` where
loader options as well as invocations of methods like
:meth:`_orm.Query.join` would fail if the left side of the statement for
which the option/join depends upon were replaced by using the
:meth:`_orm.Query.with_entities` method, or when using 2.0 style queries
when using the :meth:`_sql.Select.with_only_columns` method. A new set of
state has been added to the objects which tracks the "left" entities that
the options / join were made against which is memoized when the lead
entities are changed.

Fixes: #6503
Fixes: #6253
Change-Id: I211b2af98b0b20d1263fb15dc513884dcc5de6a4

show more ...


# 460bed7c 28-May-2021 Mike Bayer <mike_mp@zzzcomputing.com>

Fix adaption in AnnotatedLabel; repair needless expense in coercion

Fixed regression involving clause adaption of labeled ORM compound
elements, such as single-table inheritance discrimi

Fix adaption in AnnotatedLabel; repair needless expense in coercion

Fixed regression involving clause adaption of labeled ORM compound
elements, such as single-table inheritance discriminator expressions with
conditionals or CASE expressions, which could cause aliased expressions
such as those used in ORM join / joinedload operations to not be adapted
correctly, such as referring to the wrong table in the ON clause in a join.

This change also improves a performance bump that was located within the
process of invoking :meth:`_sql.Select.join` given an ORM attribute
as a target.

Fixes: #6550
Change-Id: I98906476f0cce6f41ea00b77c789baa818e9d167

show more ...


# 1481233f 26-Apr.-2021 Federico Caselli <cfederico87@gmail.com>

Remove py38 profiles

Change-Id: I726477b1c15fc6744ed16192ffca09df85bb01c8


# 45c981a0 26-Apr.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

Ensure autobegin occurs for attribute changes; Document autobegin

The Session autobegin feature was not anticipated as having
any behavioral changes other than the event hook being calle

Ensure autobegin occurs for attribute changes; Document autobegin

The Session autobegin feature was not anticipated as having
any behavioral changes other than the event hook being called
at a different time, however as autobegin impacts the behavior
of the commit() and rollback() methods in that they can now
be no-ops in non-autocommit mode, document the behavior fully.

Fixed issue where the new :ref:`session_autobegin` behavior failed to
"autobegin" in the case where an existing persistent object has an
attribute change, which would then impact the behavior of
:meth:`_orm.Session.rollback` in that no snapshot was created to be rolled
back. The "attribute modify" mechanics have been updated to ensure
"autobegin", which does not perform any database work, does occur when
persistent attributes change in the same manner as when
:meth:`_orm.Session.add` is called. This is a regression as in 1.3, the
rollback() method always had a transaction to roll back and would expire
every time.

Fixes: #6360
Fixes: #6359
Change-Id: I69f231a206f49e3231275d23bbe2cafd4e2bf3ba

show more ...


# 37414a75 21-Apr.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

Add new "sync once" mode for pool.connect

Fixed critical regression caused by the change in :ticket`5497` where the
connection pool "init" phase no longer occurred within mutexed isolati

Add new "sync once" mode for pool.connect

Fixed critical regression caused by the change in :ticket`5497` where the
connection pool "init" phase no longer occurred within mutexed isolation,
allowing other threads to proceed with the dialect uninitialized, which
could then impact the compilation of SQL statements.

This issue is essentially the same regression which was fixed many years
ago in :ticket:`2964` in dd32540dabbee0678530fb1b0868d1eb41572dca,
which was missed this time as the test suite fo
that issue only tested the pool in isolation, and assumed the
"first_connect" event would be used by the Engine. However
:ticket:`5497` stopped using "first_connect" and no test detected
the lack of mutexing, that has been resolved here through
the addition of more tests.

This fix also identifies what is probably a bug in earlier versions
of SQLAlchemy where the "first_connect" handler would be cancelled
if the initializer failed; this is evidenced by
test_explode_in_initializer which was doing a reconnect due to
c.rollback() yet wasn't hanging. We now solve this issue by
preventing the manufactured Connection from ever reconnecting
inside the first_connect handler.

Also remove the "_sqla_unwrap" test attribute; this is almost
not used anymore however we can use a more targeted
wrapper supplied by the testing.engines.proxying_engine
function.

See if we can also open up Oracle for "ad hoc engines" tests
now that we have better connection management logic.

Fixes: #6337
Change-Id: I4a3476625c4606f1a304dbc940d500325e8adc1a

show more ...


# dca3a43d 07-Apr.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

Fix LegacyRow/Row index access

Fixed up the behavior of the :class:`_result.Row` object when dictionary
access is used upon it, meaning converting to a dict via ``dict(row)`` or
acce

Fix LegacyRow/Row index access

Fixed up the behavior of the :class:`_result.Row` object when dictionary
access is used upon it, meaning converting to a dict via ``dict(row)`` or
accessing members using strings or other objects i.e. ``row["some_key"]``
works as it would with a dictionary, rather than raising ``TypeError`` as
would be the case with a tuple, whether or not the C extensions are in
place. This was originally supposed to emit a 2.0 deprecation warning for
the "non-future" case using :class:`_result.LegacyRow`, and was to raise
``TypeError`` for the "future" :class:`_result.Row` class. However, the C
version of :class:`_result.Row` was failing to raise this ``TypeError``,
and to complicate matters, the :meth:`_orm.Session.execute` method now
returns :class:`_result.Row` in all cases to maintain consistency with the
ORM result case, so users who didn't have C extensions installed would
see different behavior in this one case for existing pre-1.4 style
code.

Therefore, in order to soften the overall upgrade scheme as most users have
not been exposed to the more strict behavior of :class:`_result.Row` up
through 1.4.6, :class:`_result.LegacyRow` and :class:`_result.Row` both
provide for string-key access as well as support for ``dict(row)``, in all
cases emitting the 2.0 deprecation warning when ``SQLALCHEMY_WARN_20`` is
enabled. The :class:`_result.Row` object still uses tuple-like behavior for
``__contains__``, which is probably the only noticeable behavioral change
compared to :class:`_result.LegacyRow`, other than the removal of
dictionary-style methods ``values()`` and ``items()``.

Also remove filters for result set warnings.

callcounts updated for 2.7/ 3.9, am pushing jenkins to use python 3.9
now

Fixes: #6218
Change-Id: Ia69b974f3dbc46943c57423f57ec82323c8ae63b

show more ...


# 0e104960 13-Feb.-2021 Mike Bayer <mike_mp@zzzcomputing.com>

expand and further generalize bound parameter translate

Continued with the improvement made as part of :ticket:`5653` to further
support bound parameter names, including those generated

expand and further generalize bound parameter translate

Continued with the improvement made as part of :ticket:`5653` to further
support bound parameter names, including those generated against column
names, for names that include colons, parenthesis, and question marks, as
well as improved test support, so that bound parameter names even if they
are auto-derived from column names should have no problem including for
parenthesis in psycopg2's "pyformat" style.

As part of this change, the format used by the asyncpg DBAPI adapter (which
is local to SQLAlchemy's asyncpg diaelct) has been changed from using
"qmark" paramstyle to "format", as there is a standard and internally
supported SQL string escaping style for names that use percent signs with
"format" style (i.e. to double percent signs), as opposed to names that use
question marks with "qmark" style (where an escaping system is not defined
by pep-249 or Python).

Fixes: #5941
Change-Id: Id86f5af81903d7063a8e3505e60df56490f85358

show more ...


# 22f65156 09-Jan.-2021 Gord Thompson <gord@gordthompson.com>

Replace with_labels() and apply_labels() in ORM/Core

Replace :meth:`_orm.Query.with_labels` and
:meth:`_sql.GenerativeSelect.apply_labels` with explicit getters and
setters ``get_lab

Replace with_labels() and apply_labels() in ORM/Core

Replace :meth:`_orm.Query.with_labels` and
:meth:`_sql.GenerativeSelect.apply_labels` with explicit getters and
setters ``get_label_style`` and ``set_label_style`` to accommodate the
three supported label styles: ``LABEL_STYLE_DISAMBIGUATE_ONLY`` (default),
``LABEL_STYLE_TABLENAME_PLUS_COL``, and ``LABEL_STYLE_NONE``.

In addition, for Core and "future style" ORM queries,
``LABEL_STYLE_DISAMBIGUATE_ONLY`` is now the default label style. This
style differs from the existing "no labels" style in that labeling is
applied in the case of column name conflicts; with ``LABEL_STYLE_NONE``, a
duplicate column name is not accessible via name in any case.

For legacy ORM queries using :class:`_query.Query`, the table-plus-column
names labeling style applied by ``LABEL_STYLE_TABLENAME_PLUS_COL``
continues to be used so that existing test suites and logging facilities
see no change in behavior by default, however this style of labeling is no
longer required for SQLAlchemy queries to function, as result sets are
commonly matched to columns using a positional approach since SQLAlchemy
1.0.

Within test suites, all use of apply_labels() / use_labels
now uses the new methods. New tests added to
test/sql/test_deprecations.py nad test/orm/test_deprecations.py
to cover just the old apply_labels() method call. Tests
in ORM that made explicit use apply_labels()/ etc. where it isn't needed
for the ORM to work correctly use default label style now.

Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Fixes: #4757
Change-Id: I5fdcd2ed4ae8c7fe62f8be2b6d0e8f66409b6a54

show more ...


# 77c9534d 12-Dec.-2020 Mike Bayer <mike_mp@zzzcomputing.com>

Major revisals to lambdas

1. Improve coercions._deep_is_literal to check sequences
for clause elements, thus allowing a phrase like
lambda: col.in_([literal("x"), literal("y")]) to b

Major revisals to lambdas

1. Improve coercions._deep_is_literal to check sequences
for clause elements, thus allowing a phrase like
lambda: col.in_([literal("x"), literal("y")]) to be handled

2. revise closure variable caching completely. All variables
entering must be part of a closure cache key or rejected.
only objects that can be resolved to HasCacheKey or FunctionType
are accepted; all other types are rejected. This adds a high
degree of strictness to lambdas and will make them a little more
awkward to use in some cases, however prevents several classes
of critical issues:

a. previously, a lambda that had an expression derived from
some kind of state, like "self.x", or "execution_context.session.foo"
would produce a closure cache key from "self" or "execution_context",
objects that can very well be per-execution and would therefore
cause a AnalyzedFunction objects to overflow. (memory won't leak
as it looks like an LRUCache is already used for these)

b. a lambda, such as one used within DeferredLamdaElement, that
produces different SQL expressions based on the arguments
(which is in fact what it's supposed to do), however it would
through the use of conditionals produce different bound parameter
combinations, leading to literal parameters not tracked properly.
These are now rejected as uncacheable whereas previously they would
again be part of the closure cache key, causing an overflow of
AnalyizedFunction objects.

3. Ensure non-mapped mixins are handled correctly by
with_loader_criteria().

4. Fixed bug in lambda SQL system where we are not supposed to allow a Python
function to be embedded in the lambda, since we can't predict a bound value
from it. While there was an error condition added for this, it was not
tested and wasn't working; an informative error is now raised.

5. new docs for lambdas

6. consolidated changelog for all of these

Fixes: #5760
Fixes: #5765
Fixes: #5766
Fixes: #5768
Fixes: #5770
Change-Id: Iedaa636c3225fad496df23b612c516c8ab247ab7

show more ...


# 93cc9d7e 02-Dec.-2020 Federico Caselli <cfederico87@gmail.com>

Replace ``OrderedDict`` with a normal ``dict`` in python 3.7+

References: #5735

Change-Id: I0a73f727fb6820d32eca590b1e8afbfe2872adb8


# f016c1ac 02-Nov.-2020 Mike Bayer <mike_mp@zzzcomputing.com>

Reduce import time overhead

* Fix subclass traversals to not run classes multiple times

* switch compiler visitor to use an attrgetter, to avoid
an eval() at startup time

Reduce import time overhead

* Fix subclass traversals to not run classes multiple times

* switch compiler visitor to use an attrgetter, to avoid
an eval() at startup time

* don't pre-generate traversal functions, there's lots of these
which are expensive to generate at once and most applications
won't use them all; have it generate them on first use instead

* Some ideas about removing asyncio imports, they don't seem to
be too signficant, apply some more simplicity to the overall
"greenlet fallback" situation

Fixes: #5681
Change-Id: Ib564ddaddb374787ce3e11ff48026e99ed570933

show more ...


# f483573a 29-Sep.-2020 Mike Bayer <mike_mp@zzzcomputing.com>

Scan for tables without relying upon whereclause

Fixed bug where an UPDATE statement against a JOIN using MySQL multi-table
format would fail to include the table prefix for the target t

Scan for tables without relying upon whereclause

Fixed bug where an UPDATE statement against a JOIN using MySQL multi-table
format would fail to include the table prefix for the target table if the
statement had no WHERE clause, as only the WHERE clause were scanned to
detect a "multi table update" at that particular point. The target
is now also scanned if it's a JOIN to get the leftmost table as the
primary table and the additional entries as additional FROM entries.

Fixes: #5617
Change-Id: I26d74afebe06e28af28acf960258f170a1627823

show more ...


# 92a8ead7 27-Sep.-2020 Mike Bayer <mike_mp@zzzcomputing.com>

build the full compilestate every time

the ORMSelectCompileState was trying to get away with
not building out the "froms" list of the state, but we need
this for select.froms. Buil

build the full compilestate every time

the ORMSelectCompileState was trying to get away with
not building out the "froms" list of the state, but we need
this for select.froms. Build this out and add some tests
for select(), including some other state-oriented use cases.

Fixes: #5614
Change-Id: I29ca200f292cbae87c722bc97a89d7c453d7d27a

show more ...


# a1939719 19-Aug.-2020 Mike Bayer <mike_mp@zzzcomputing.com>

normalize execute style for events, 2.0

The _execute_20 and exec_driver_sql methods should wrap
up the parameters so that they represent the single list / single
dictionary style of

normalize execute style for events, 2.0

The _execute_20 and exec_driver_sql methods should wrap
up the parameters so that they represent the single list / single
dictionary style of invocation into the legacy methods. then
the before_ after_ execute event handlers should be receiving
the parameter dictionary as a single dictionary. this requires
that we break out distill_params to work differently if event
handlers are present.

additionally, add deprecation warnings for old argument passing
styles.

Change-Id: I97cb4d06adfcc6b889f10d01cc7775925cffb116

show more ...


# 24a9e697 27-Jul.-2020 Federico Caselli <cfederico87@gmail.com>

Add complete platform data to profiling data

Initially to distinsuish between arm and x86_64
architecture, expand out the profile key to include
machine, system, python impl in all c

Add complete platform data to profiling data

Initially to distinsuish between arm and x86_64
architecture, expand out the profile key to include
machine, system, python impl in all cases.

Ref: #5436
Change-Id: I7e48f0462ba7d9c680b2dac45ce7b0cf709b9b22

show more ...


# 71a3ccbd 05-Aug.-2020 Mike Bayer <mike_mp@zzzcomputing.com>

Convert lazy loader, selectinload, load_on_ident to lambda statements

Building on newly robust lambdas in
I29a513c98917b1d503abfdd61e6b6e8800851aa8,
convert key loading off of the "b

Convert lazy loader, selectinload, load_on_ident to lambda statements

Building on newly robust lambdas in
I29a513c98917b1d503abfdd61e6b6e8800851aa8,
convert key loading off of the "baked" system so that baked
is no longer used by the ORM.

Change-Id: I3abfb45dd6e50f84f29d39434caa0b550ce27864

show more ...


# 91f37669 26-Jun.-2020 Mike Bayer <mike_mp@zzzcomputing.com>

Add future=True to create_engine/Session; unify select()

Several weeks of using the future_select() construct
has led to the proposal there be just one select() construct
again which

Add future=True to create_engine/Session; unify select()

Several weeks of using the future_select() construct
has led to the proposal there be just one select() construct
again which features the new join() method, and otherwise accepts
both the 1.x and 2.x argument styles. This would make
migration simpler and reduce confusion.

However, confusion may be increased by the fact that select().join()
is different Current thinking is we may be better off
with a few hard behavioral changes to old and relatively unknown APIs
rather than trying to play both sides within two extremely similar
but subtly different APIs. At the moment, the .join() thing seems
to be the only behavioral change that occurs without the user
taking any explicit steps. Session.execute() will still
behave the old way as we are adding a future flag.

This change also adds the "future" flag to Session() and
session.execute(), so that interpretation of the incoming statement,
as well as that the new style result is returned, does not
occur for existing applications unless they add the use
of this flag.

The change in general is moving the "removed in 2.0" system
further along where we want the test suite to fully pass
even if the SQLALCHEMY_WARN_20 flag is set.

Get many tests to pass when SQLALCHEMY_WARN_20 is set; this
should be ongoing after this patch merges.

Improve the RemovedIn20 warning; these are all deprecated
"since" 1.4, so ensure that's what the messages read.
Make sure the inforamtion link is on all warnings.
Add deprecation warnings for parameters present and
add warnings to all FromClause.select() types of methods.

Fixes: #5379
Fixes: #5284
Change-Id: I765a0b912b3dcd0e995426427d8bb7997cbffd51
References: #5159

show more ...


# 3dc9a4a2 16-Dec.-2019 Mike Bayer <mike_mp@zzzcomputing.com>

introduce deferred lambdas

The coercions system allows us to add in lambdas as arguments
to Core and ORM elements without changing them at all. By allowing
the lambda to produce a

introduce deferred lambdas

The coercions system allows us to add in lambdas as arguments
to Core and ORM elements without changing them at all. By allowing
the lambda to produce a deterministic cache key where we can also
cheat and yank out literal parameters means we can move towards
having 90% of "baked" functionality in a clearer way right in
Core / ORM.

As a second step, we can have whole statements inside the lambda,
and can then add generation with __add__(), so then we have
100% of "baked" functionality with full support of ad-hoc
literal values.

Adds some more short_selects tests for the moment for comparison.

Other tweaks inside cache key generation as we're trying to
approach a certain level of performance such that we can
remove the use of "baked" from the loader strategies.

As we have not yet closed #4639, however the caching feature
has been fully integrated as of
b0cfa7379cf8513a821a3dbe3028c4965d9f85bd, we will also
add complete caching documentation here and close that issue
as well.

Closes: #4639
Fixes: #5380
Change-Id: If91f61527236fd4d7ae3cad1f24c38be921c90ba

show more ...


# 0286dcb2 28-Jun.-2020 Mike Bayer <mike_mp@zzzcomputing.com>

Remove _generate_path_cache_key()

loader options can now make a deterministic cache key based
on the structure they are given, and this accommodates for
aliased classes as well so t

Remove _generate_path_cache_key()

loader options can now make a deterministic cache key based
on the structure they are given, and this accommodates for
aliased classes as well so that these cache keys are now
"safe". Have baked query call upon
the regular cache key method.

Change-Id: Iaa2ef4064cfb16146f415ca73080f32003dd830d

show more ...


# 9272ae4f 28-May-2020 Mike Bayer <mike_mp@zzzcomputing.com>

Remove loader option cycle

removed a reference cycle set up by loader options
due to the attribute dictionary containing Load objects
that reference that dictionary.

Change-

Remove loader option cycle

removed a reference cycle set up by loader options
due to the attribute dictionary containing Load objects
that reference that dictionary.

Change-Id: Ie3159a084f819ae44ca4992b0dbe094fb69b2fa7

show more ...


1234567