Feature Request: Safe Node Inflation with Extra Labels (__unsafe_inflating__)

[OlehChyhyryn]

Currently, Neo4j has a conflict between using labels to store information about nodes and resolving those nodes from the database.

Imagine you have the following node structure:

class A(StructuredNode):
…

class B(A):
…

class C(B):
…

Now, let’s say you add some additional labels to the C node directly in the Neo4j browser interface.

If you then try to fetch this node using get_or_none, you’ll get the following error:

neomodel.exceptions.NodeClassNotDefined: Node with labels A,B,C,Label_1,Label_2 does not resolve to any of the known objects.

There is already a mechanism with optional_labels in Neomodel, but it’s not suitable for our scenario because we have many additional labels that represent properties rather than types.

⸻

Proposal

Introduce a __unsafe_inflating__ property for a node class.

This flag would allow the node to be inflated from the database if the set of labels on the node includes a singular, non-conflicting subset that matches a known node definition in the resolver.

In other words, instead of adding combinations to the resolver map like optional_labels does, it would search for a matching subset of labels—ideally the first valid one—that is known to the registry.

This should not be the default behavior due to the performance cost of doing the search.

Alternatively, this flag could modify how optional_labels works: instead of registering the labels into the resolver map, it would just ignore them during resolution.

[aanastasiou]

@OlehChyhyryn I would vote against this proposal because this functionality would be stretching the role of the OGM.

It would be useful if you can share more details about what you are trying to achieve but going by what you mention in this post, I would suggest that instead of loading the nodes with labels, you add them as node properties and then create an index over those properties.

More generally though, having adopted an OGM (Object Graph Mapper) such as Neomodel, manual changes would have to be limited as much as possible and applied only via the model.