Bumps [psycopg](https://github.com/psycopg/psycopg) from 3.2.4 to 3.2.5.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/psycopg/psycopg/blob/master/docs/news.rst">psycopg's
changelog</a>.</em></p>
<blockquote>
<p>.. currentmodule:: psycopg</p>
<p>.. index::
single: Release notes
single: News</p>
<h1><code>psycopg</code> release notes</h1>
<h2>Future releases</h2>
<p>Python 3.3.0 (unreleased)
^^^^^^^^^^^^^^^^^^^^^^^^^</p>
<ul>
<li>Drop support for Python 3.8.</li>
</ul>
<h2>Current release</h2>
<p>Psycopg 3.2.5
^^^^^^^^^^^^^</p>
<ul>
<li>3x faster UUID loading thanks to C implementation
(🎟️<code>[#447](https://github.com/psycopg/psycopg/issues/447),
[#998](https://github.com/psycopg/psycopg/issues/998)</code>).</li>
</ul>
<p>Psycopg 3.2.4
^^^^^^^^^^^^^</p>
<ul>
<li>Don't lose notifies received whilst the
<code>~Connection.notifies()</code> iterator
is not running
(🎫<code>[#962](https://github.com/psycopg/psycopg/issues/962)</code>).</li>
<li>Make sure that the notifies callback is called during the use of the
<code>~Connection.notifies()</code> generator
(🎫<code>[#972](https://github.com/psycopg/psycopg/issues/972)</code>).</li>
<li>Raise the correct error returned by the database (such as
<code>!AdminShutdown</code>
or <code>!IdleInTransactionSessionTimeout</code>) instead of a generic
<code>OperationalError</code> when a server error causes a client
disconnection
(🎫<code>[#988](https://github.com/psycopg/psycopg/issues/988)</code>).</li>
<li>Build macOS dependencies from sources instead using the Homebrew
versions
in order to avoid problems with <code>MACOSX_DEPLOYMENT_TARGET</code>
(🎫<code>[#858](https://github.com/psycopg/psycopg/issues/858)</code>).</li>
<li>Bump libpq to 17.2 in Linux and macOS binary packages.</li>
<li>Bump libpq to 16.4 in Windows binary packages, using the <code>vcpkg
library</code>__
(🎫<code>[#966](https://github.com/psycopg/psycopg/issues/966)</code>).</li>
</ul>
<p>.. __: <a
href="https://vcpkg.io/en/package/libpq">https://vcpkg.io/en/package/libpq</a></p>
<p>Psycopg 3.2.3
^^^^^^^^^^^^^</p>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="664b2a12d6"><code>664b2a1</code></a>
chore: bump psycopg package version to 3.2.5</li>
<li><a
href="cd6589bf35"><code>cd6589b</code></a>
chore: bump build libraries</li>
<li><a
href="68f8603ec6"><code>68f8603</code></a>
Merge branch 'cython-uuid-3.2' into maint-3.2</li>
<li><a
href="dd1cefc3ee"><code>dd1cefc</code></a>
docs: mention UUID speedup in release news</li>
<li><a
href="7f950cb843"><code>7f950cb</code></a>
chore(c): remove C UUIDDumper and UUIDBinaryDumper</li>
<li><a
href="393e162fc3"><code>393e162</code></a>
perf(uuid): speed up UUID creation using a writable subclass</li>
<li><a
href="57a3889949"><code>57a3889</code></a>
perf(c): use PyObject_CallFunctionObjArgs in UUIDBinaryLoader</li>
<li><a
href="88f73fedd2"><code>88f73fe</code></a>
perf(c): use PyObject_CallFunctionObjArgs in UUIDLoader</li>
<li><a
href="3a9ade78e7"><code>3a9ade7</code></a>
test(c): test UUID.<strong>slots</strong></li>
<li><a
href="811cb51123"><code>811cb51</code></a>
perf(c): Use hex_to_int_map in UUIDLoader</li>
<li>Additional commits viewable in <a
href="https://github.com/psycopg/psycopg/compare/3.2.4...3.2.5">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
- always redirect user from map to their profile page when they used a
deprecated backend to log in
- change the Twitter image to make clear it is to be removed
- always redirect user from map to their profile page when they
used a deprecated backend to log in
- change the Twitter image to make clear it is to be removed
Co-authored-by: David Larlet <david@larlet.fr>
We think it's useless now that we use "editable:edited" event everywhere
(vs using the "editable:commit" which was triggered also after a delete,
when closing the edit panel)
That fix does not really fix the original issue, but it makes it
impactless, and I think it's safer anyway to have upsert idempotent.
The pattern to reproduce is:
- peer A create a synced map, add a datalayer, save it
- peer B loads the map, click on edit
- at this time, peer B have twice the datalayer data, once from the
server AND once from the sync
So a better fix would be to make that peer B send a meaningfull HLC to
peer A I guess.
For this we may save the last HLC is the map properties, or maybe try to
merge the "reference_version" and the HLC.
I first tried to handle this on Leaflet.Editable side, to make it fire
the "editable:edited" event we use to trigger the sync, but deciding
what to do with a feature on escape needs some decisions that seems hard
to implement in a generic way in Leaflet.Editable.
We call stopDrawing, which then calls cancelDrawing, so here one need to
decide if cancelDrawing should keep the already drawn line (but cancel
the point being drawn) or cancel everything.
This is why I end up making this change in uMap itself.
To reproduce:
- create a map
- saved it
- change the "syncEnabled" setting to on
- save again
- open another tab with this map
- switch on edit mode
In this case, the second client will try to authenticate:
- once switch on edit mode
- and once receiving the operation message from peer A about the
syncEnabled (which calls render, which calls initSyncEngine in in this
case)
I think we want to keep render to call initSyncEngine, so if a map owner
switch off the syncEnabled setting, this will (should) disconnect the
other peers.
That fix does not really fix the original issue, but it make it impactless.
The pattern is:
- peer A create a synced map, add a datalayer, save it
- peer B loads the map, click on edit
- at this time, peer B have twice the datalayer data, once from the server
AND once from the sync
So a better fix would be to make that peer B send a meaningfull HLC to
peer A I guess.
For this we may save the last HLC is the map properties, or maybe try
to merge the "reference_version" and the HLC.
I first tried to handle this on Leaflet.Editable side, to make
it fire the "editable:edited" event we use to trigger the sync,
but deciding what to do with a feature on escape needs some
decisions that seems hard to implement in a generic way in
Leaflet.Editable.
We call stopDrawing, which then calls cancelDrawing, so here
one need to decide if cancelDrawing should keep the already
drawn line (but cancel the point being drawn) or cancel
everything.
This is why I end up making this change in uMap itself.
To reproduce:
- create a map
- saved it
- change the "syncEnabled" setting to on
- save again
- open another tab with this map
- switch on edit mode
In this case, the second client will try to authenticate:
- once switch on edit mode
- and once receiving the operation message from peer A about the
syncEnabled (which calls render, which calls initSyncEngine in
in this case)
I think we want to keep render to call initSyncEngine, so if a map
owner switch off the syncEnabled setting, this will (should) disconnect
the other peers.
