JSON path equality against a non-string value: silently empty on MySQL, raises on PostgreSQL
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 75/100
Piste de recherche
Start in condition.py around prep_value at line 336, then trace adapter.json_path_expr for the MySQL and PostgreSQL implementations. Reproduce the listed restrictions against both backends and add regression coverage for string, integer, and boolean values. Done means JSON-path comparisons behave consistently across backends and never silently return wrong rows.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Table & {"json_attr.field": value} only behaves correctly when value is a string. A Python bool returns the wrong answer on MySQL and raises on PostgreSQL; a Python int raises on PostgreSQL.
Sibling of #1563 — same root (JSON extraction yields text), different side: that one is the :type annotation on projection, this one is the Python value on restriction.
Repro
@schema
class E(dj.Manual):
definition = """
name : varchar(32)
---
s : json
"""
E.insert([
{"name": "a", "s": {"vendor": "Acme", "ch": 64, "cal": True}},
{"name": "b", "s": {"vendor": "Other", "ch": 16, "cal": False}},
])
Each row should select ['a']:
| restriction | MySQL 8.0 | postgres:15 |
|---|---|---|
& {"s.vendor": "Acme"} |
['a'] |
['a'] |
& {"s.ch": 64} |
['a'] |
UndefinedFunction: operator does not exist: text = integer |
& {"s.ch": "64"} |
['a'] |
['a'] |
& {"s.cal": True} |
[] |
UndefinedFunction: operator does not exist: text = boolean |
& {"s.cal": "true"} |
['a'] |
['a'] |
The MySQL boolean row is the serious one: no error, no rows, and the natural reading of an empty result is "nothing is calibrated."
Cause
adapter.json_path_expr yields json_value(...) / jsonb_extract_path_text(...), both of which return text. prep_value (condition.py:336) then renders the Python value by its own type, so the comparison becomes text = <non-text>:
- PostgreSQL refuses the comparison outright.
- MySQL coerces for numerics, which is why
64happens to work, but compares the extractedtrueagainst1for a bool and matches nothing.
The asymmetry is invisible to a user: the same expression is correct, wrong, or an error depending on the value's Python type and the backend.
Suggested fix
On the JSON-path branch of prep_value, render the comparison value as text — or cast the extraction to the value's type — so that True, 64 and "Acme" all behave the same way on both backends.
Whichever way, a bool must not silently match nothing. If a given comparison cannot be made portable, raising is acceptable; returning the wrong rows is not.
Documentation
This is almost certainly why tutorials/advanced/json-type.ipynb teaches "Filtering on JSON Content — fetch then filter in Python" and lists "Filter in Python" as an inherent property of JSON in its Design Guidelines. Server-side filtering does work, with the value passed as a string; the tutorial's advice reads as a limitation of the type rather than of this behavior. Worth revisiting together.
- Langage dominant
- Python
- Étoiles
- 197
- Forks
- 98
- Merge moyen
- 23 h 9 min
- PR mergées (30 j)
- 6
Préparer son environnement
- Fournit un Dockerfile ou un fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de datajoint/datajoint-python
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
datajoint/datajoint-python#1539 · 3 commentaires ·
-
Python 3.15 ships Oct 9 and we cap below it; 3.10 went EOL Oct 1Peut-être pris @dimitri-yatsenko l’a pris il y a 1 jour. Ouverteenhancement
datajoint/datajoint-python#1569 · 1 personne assignée ·
-
JSON path type annotation is not portable: `data.n:int` works on PostgreSQL, raises on MySQLOuvertebug
Difficulté 4/5 3-5 jours Accessibilité débutants 68/100
datajoint/datajoint-python#1563 ·
-
enhancement
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
datajoint/datajoint-python#1562 · 2 commentaires ·
-
bug
Difficulté 3/5 1-2 jours Accessibilité débutants 75/100
datajoint/datajoint-python#1561 · 1 commentaire ·
Toutes les issues de datajoint/datajoint-python
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
LearningCircuit/local-deep-research#7206 ·
Les mainteneurs répondent en général sous 1 jour
-
[TASK] Document technology stackOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
chingu-voyages/V62-tier3-team-33#285 ·
Les mainteneurs répondent en général sous 1 jour
-
Proxy drops log notifications from backends that don't send FastMCP's msg/extra dictPeut-être pris @asasemahmed l’a pris aujourd’hui. Ouvertebug server
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour
-
[Bug]: Bedrock request metadata forwarding does not work for /embeddingsPeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouvertebug llm translation
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour