Hi,
There is a patch that was posted yesterday (September 1st) that aims
to fix this but it is considered a stop-gap measure and not the ideal
fix. Others have not weighed in on how effective this stop-gap measure
is. And it is acknowledged that the ideal fix is out-of-scope for 19.
Global vs per-label scoping of labels and properties:
---
A view over a GRAPH_TABLE becomes silently unqueryable after a
property/label is dropped from one element when it still exists
elsewhere in the graph.
Ashutosh has analyzed the standard and has an interpretation of what
the correct behavior should be with RESTRICT vs CASCADE, but others
have not weighed in. Additionally, there is an unanswered question
around what should happen for a function/property shared across two
labels.
There is not a posted fix for this yet, the desired behavior in some
cases is unresolved pending an interpretation of the standard, and
there is acknowledgement that a more correct fix is
association-granularity dependencies which is out of scope for 19.
I was planning on replying about this patch set, since I started going
through it yesterday/this morning. The one in this series that gives me
the most pause is v20260901-0004, because it introduces
property-graph-specific deletion planning into dependency.c. To me,
that reads as compensation for the property-graph-related objects not
being represented cleanly enough in the first place. I understand this
is a stop-gap for v19, but I am not sure we should accept a stop-gap
that introduces this kind of design violation.
The situation here is a bit unusual, because what we really need to
know is whether deleting a given row removes the last remaining
reference to the shared property-graph object. The approach in
v20260901-0004 seems to work, but only by teaching dependency.c far too
much about property graphs. After findDependentObjects() has built the
initial deletion set, this otherwise generic code path now needs an
extra property-graph-specific orphan-cleanup pass.
