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. -- Sami Imseih Amazon Web Services (AWS)
