Django-pgclone

Latest version: v3.6.0

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

Scan your dependencies

Page 2 of 5

3.2.0

Feature

- Add Python3.12 support and use Mkdocs for documentation [Wesley Kendall, 97e7d99]

Python 3.12 and Postgres 16 are supported now, along with having revamped docs using Mkdocs
and the Material theme.

Python 3.7 support was dropped.

3.1.0

Feature

- Added Python 3.11, Django 4.2, and Psycopg 3 support [Wesley Kendall, d1cf98c]

Adds Python 3.11, Django 4.2, and Psycopg 3 support along with tests for multiple Postgres versions. Drops support for Django 2.2.

3.0.0

Api-Break

- Changed behavior of reversible restores and local copies [Wes Kendall, de428c1]

Using the ``--reversible`` option for ``pgclone restore`` is now only applicable to
database dumps and no longer has any effect when executed against a local database.
The aliases used by reversible restores have also changed from ``previous`` and
``current`` to ``pre`` and ``post``.

In other words, if one uses ``--reversible`` during a ``pgclone restore`` of
a database dump, one can revert back to the version of data pre-restore using
``pgclone restore :pre`` or the version of the data immediately after
the restore using ``pgclone restore :post``.

Unlike before, running ``pgclone restore :pre`` or ``pgclone restore :post`` has
no effect on the copies created when restoring a dump using ``--reversible``.
The ``:pre`` and ``:post`` aliases are only changed when a new reversible dump
is restored.

This same behavior applies to local copies too. ``pclone copy`` now requires
a target name in the format of a local dump key (``:db_name``), and the special
``:pre`` and ``:post`` aliases cannot be used. Users can do
``pgclone copy :my_backup`` and ``pgclone restore :my_backup`` without affecting
the special snapshots related to the last restore from a dump.

2.6.0

Feature

- Support overriding Postgres statement timeouts [Wes Kendall, 4ef38f4]

Use ``settings.PGCLONE_STATEMENT_TIMEOUT`` to override Postgres's
``statement_timeout`` setting when running core ``pgclone`` SQL operations such
as ``CREATE DATABASE``.

You can also use ``settings.PGCLONE_LOCK_TIMEOUT`` to override Postgres's
``lock_timeout`` setting.

2.5.0

Feature

- Add ``pgclone copy`` command. [Wes Kendall, 6ad17b9]

The ``pgclone copy`` command is a shortcut for running ``CREATE DATABASE <target> TEMPLATE <source>``
for doing quick copies. This command complements local ``pgclone restore`` commands.

For example, copy the current database with ``pgclone copy``, and quickly restore it with
``pgclone restore :current``. Use a custom name with ``pgclone copy :custom_name`` and restore it
with ``pgclone restore :custom_name``.

Note that this command takes out an exclusive lock on the source database, meaning it should not be
executed in production environments.
- Add ``settings.PGCLONE_ALLOW_DUMP`` setting. [Wes Kendall, 82c90f4]

Set this setting to ``False`` to prevent the ability to run ``pgclone dump``.

Trivial

- Add ability to specify endpoint url [Jack Linke, 2e1e5f5]

2.4.0

Bug

- Quote database connection strings [Wesley Kendall, 31fd3cf]

Database connection strings are properly quoted to avoid issues when there
are special characters.

Trivial

- Updated developer utilities with the latest Django library template [Wesley Kendall, 2508920]

Page 2 of 5

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.