Relstorage

Latest version: v4.1.1

Safety actively analyzes 701671 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 11 of 14

1.6.1

Not secure
==================

- Tests: Basic integration testing is done on Travis CI. Thanks to
Mauro Amico.

- ``RelStorage.lastTransaction()`` is more consistent with FileStorage
and ClientStorage, returning a useful value in more cases.

- zodbconvert: The ``--incremental`` option is supported with a
FileStorage (or any storage that implements
``IStorage.lastTransaction()``) as a destination, not just
RelStorages.

- zodbconvert: The ``--incremental`` option is supported with a
RelStorage as a destination. See :pr:`22`. With contributions by
Sylvain Viollon, Mauro Amico, and Peter Jacobs. Originally reported
by Jan-Wijbrand Kolman.

- Oracle: Packing should no longer produce LOB errors. This partially
reverts the speedups in 1.6.0b2. Reported in :issue:`30` by Peter
Jacobs.

1.6.0

Not secure
==================

- Tests: Use the standard library doctest module for compatibility
with newer zope.testing releases.

1.6.0b3

Not secure
====================

- Packing: Significantly reduced the RAM consumed by graph traversal during
the pre_pack phase. (Tried several methods; encoded 64 bit IISets turned
out to be the most optimal.)

1.6.0b2

Not secure
====================

- Packing: Used cursor.fetchmany() to make packing more efficient.

1.6.0b1

Not secure
====================

- The local cache is now more configurable and uses ``zlib`` compression
by default.

- Added support for ``zodburi``, which means you can open a storage
using "postgres:", "mysql:", or "oracle:" URIs.

- Packing: Reduced RAM consumption while packing by using IIBTree.Set
instead of built-in set objects.

- MySQL 5.5: The test suite was freezing in checkBackwardTimeTravel. Fixed.

- Added performance metrics using the perfmetrics package.

- zodbconvert: Add an --incremental option to the zodbconvert script,
letting you convert additional transactions at a later date, or
update a non-live copy of your database, copying over missing
transactions.

- Replication: Added the ro-replica-conf option, which tells RelStorage
to use a read-only database replica for load connections. This makes
it easy for RelStorage clients to take advantage of read-only
database replicas.

- Replication: When the database connection is stale (such as when
RelStorage switches to an asynchronous replica that is not yet up to
date), RelStorage will now raise ReadConflictError by default.
Ideally, the application will react to the error by transparently
retrying the transaction, while the database gets up to date. A
subsequent transaction will no longer be stale.

- Replication: Added the revert-when-stale option. When this option is
true and the database connection is stale, RelStorage reverts the
ZODB connection to the stale state rather than raise
ReadConflictError. This option is intended for highly available,
read-only ZODB clients. This option would probably confuse users of
read-write ZODB clients, whose changes would sometimes seem to be
temporarily reverted.

- Caching: Use the database name as the cache-prefix by default. This
will hopefully help people who accidentally use a single memcached for
multiple databases.

- Fixed compatibility with persistent 4.0.5 and above.

1.5.1

Not secure
==================

- Packing: Lowered garbage collection object reference finding log level to
debug; this stage takes mere seconds, even in large sites, but could produce
10s of thousands of lines of log output.

- RelStorage was opening a test database connection (and was leaving it
idle in a transaction with recent ZODB versions that support
IMVCCStorage.) RelStorage no longer opens that test connection.

- zodbconvert: Avoid holding a list of all transactions in memory.

- Just after installing the database schema, verify the schema was
created correctly. This affects MySQL in particular.

Page 11 of 14

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.