Psycopg2-mq

Latest version: v0.9

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

Scan your dependencies

Page 1 of 6

0.9

----------------

- Add support for Python 3.10, and 3.11.

- [breaking] Prevent retrying of collapsible jobs. Require them to be invoked
using ``call`` instead for an opportunity to specify a ``conflict_resolver``.

- Fix a bug in the default model schema in which the collapsible database
index was not marked unique.

- Copy trace info when retrying a job.

- Capture the stringified exception to the job result in the ``message`` key,
alongside the existing ``tb``, ``exc``, and ``args`` keys.

- The worker was not recognizing ``capture_signals=False``, causing problems
when running the event loop in other threads.

- Blackify the codebase and add some real tests. Yay!

0.8.3

------------------

- [breaking] Remove ``MQWorker.make_job_context``.

0.8.2

------------------

- Drop Python 3.6 support.

- [breaking] Require SQLAlchemy 1.4+ and resolve deprecation warnings related to
SQLAlchemy 2.0.

- [breaking] Rename ``update_job_id`` to ``updated_job_id`` in the
``JobCursor`` model.

0.8.1

------------------

- Ensure the ``trace`` attribute is populated on the ``JobContext``.

- Add ``MQWorker.make_job_context`` which can be defined to completely override
the ``JobContext`` factory using the ``Job`` object and open database session.

0.8.0

------------------

- [breaking] Add ``update_job_id`` foreign key to the ``JobCursor`` model to
make it possible to know which job last updated the value in the cursor.

- [breaking] Add ``trace`` json blob to the ``Job`` model.

- Support a ``trace`` json blob when creating new jobs. This value is available
on the running job context and can be used when creating sub-jobs or when
making requests to external systems to pass through tracing metadata.

See ``MQSource.call``'s new ``trace`` parameter when creating jobs.
See ``JobContext.trace`` attribute when handling jobs.

- Add a standard ``FailedJobError`` exception which can be raised by jobs to
mark a failure with a custom result object. This is different from unhandled
exceptions that cause the ``MQWorker.result_from_error`` method to be invoked.

0.7.0

------------------

- Fix a corner case with lost jobs attached to cursors. In scenarios where
multiple workers are running, if one loses a database connection then the
other is designed to notice and mark jobs lost. However, it's possible the
job is not actually lost and the worker can then recover after resuming
its connection, and marking the job running again. In this situation, we
do not want another job to begin on the same cursor. To fix this issue,
new jobs will not be run if another job is marked lost on the same cursor.
You will be required to recover the job by marking it as not lost (probably
failed) first to unblock the rest of the jobs on the cursor.

Page 1 of 6

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.