A condition on a list read over several hops ignores a depth given for the query on the SQL stores, while the load honours it

Abierto
  • ¿Algo no está bien?
#297 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
databases

Línea de trabajo

Start with drivine/backend/sql/sql_query_renderer.py:157, then compare its depth handling with drivine/backend/sql/sql_views.py:150 and drivine/dsl/query_renderer.py:304. Port ConditionDepthCrossEngineTest and ConditionDepthRenderingTest from the referenced work to cover query-specified depths, nested views, and rendered patterns. Done when conditions and loads agree across SQL and graph engines for the described depth cases.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Port of liberation-data/drivine4j#461.

What happens here now. A condition on a list of fragments read over several hops (max_depth above 1) walks the field's depth on every store, but on the SQL stores it ignores a depth given for the query (depth={"following": 3}), while the load honours it. So the filter and the load disagree whenever a query gives a depth:

  • drivine/backend/sql/sql_query_renderer.py:157 (the hop of a condition) takes depth = rel.max_depth.
  • The load reads self.depth.get(rel.field, rel.max_depth) (drivine/backend/sql/sql_views.py:150), and so does the Cypher condition (drivine/dsl/query_renderer.py:304).

With following of max_depth=2 over a → b → c → d and depth={"following": 3}, the load gives a's following as [b, c, d], and following.any(text == "d") doesn't find a on Postgres or Oracle; with depth={"following": 1} it finds a through c, which the load leaves out.

What the fix in drivine4j does (liberation-data/drivine4j#474): the load and every condition take the depth of a field from one place (RelationshipDepth.hops: the query's depth for the field, or its maxDepth, for a list of node fragments; one hop otherwise), on the graph engines and the SQL stores alike, at the top level and on a field of a nested view.

Tests that can be ported: ConditionDepthCrossEngineTest (the chain a → b → c → d, the cycle p → q → p, a stranger at the end and in the middle of a path, holders of the windows for a nested field; any, none, empty blocks, not, an or, depths 1 and 3 given for the query, and the count beside each filter), and ConditionDepthRenderingTest for the rendered patterns.

Lenguaje dominante
Python
Estrellas
1
Forks
0
Merge medio
1 h 32 min
PR fusionados (30 d)
149

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de liberation-data/drivine-python

Todos los issues de liberation-data/drivine-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.