v12: ActiveGraph::DeprecatedSchemaDefinitionError raised for relationship models that don't use id_property

[fbuys]

Hello!

First, thank you for creating and maintaining activegraph, we appreciate the work that goes into it.

We are upgrading to v12 (activegraph 12.0.0.beta.7, neo4j-ruby-driver 6.0.3.alpha.0, Neo4j 5 Enterprise) and encountered an unexpected error caused by relationship models being registered in MODEL_CONSTRAINTS.

Background

We have relationship models that do not define or use a uuid, they are only ever accessed through node traversal, never queried directly by ID. Before v12 this worked fine.

What changed in v12

In beta.1, ensure_id_property_info! was added to ActiveGraph::Relationship#initialize (commit bcc5165). This causes relationship classes to be registered in MODEL_CONSTRAINTS via handle_model_schema!. I believe when validate_model_schema! runs, it checks Neo4j for a corresponding uniqueness constraint but there is no constraint so the check always fails.

Error

  ActiveGraph::DeprecatedSchemaDefinitionError:
    Some schema elements were defined by the model (which is no longer supported),
    but they do not exist in the database. Run the following to create them if you haven't already:

    rake neo4j:generate_schema_migration[constraint,RELATIONSHIP,uuid]

    And then run `rake neo4j:migrate`

Workaround

We worked around this by overriding ensure_id_property_info! on the affected relationship class to call super (preserving uuid assignment for new instances) and then removing the class from MODEL_CONSTRAINTS:

  def self.ensure_id_property_info!
    super
    ActiveGraph::ModelSchema::MODEL_CONSTRAINTS.delete(self)
  end

Questions

1. Is this a known issue with the beta, or is there a supported way to opt relationship models out of the id property / constraint mechanism?
2. What are your thoughts on the workaround — are there implications we may have missed?
3. Would you consider adding a first-class opt-out for relationship models that don't need uuid identity, to avoid the need for this kind of patch?

[klobuczek]

@fbuys, apologies for the late reply.
We intentionally introduced IDs on relationship-backed models for a large client, and the decision was guided by consistency with ActiveRecord. A has_many :through join model in ActiveRecord has an id by default — and for good reason.

I'd also note that if a relationship has no properties, you don't need a model for it at all, which means the unwanted id only appears when you do have a model — presumably because you're storing properties on the relationship. Once you're in that situation, consider two relationships of the same type between the same pair of nodes, each with different property values. Without an id, you have no reliable way to identify and update a specific one.

As for making the id optional: to be consistent, we'd have to make it optional on node-backed models too, which cuts against the ActiveRecord pattern more broadly. That's not a tradeoff we're inclined to make.

Your workaround is reasonable given the constraint, though calling super while then removing the class from MODEL_CONSTRAINTS is a bit contradictory — it preserves the runtime uuid assignment behavior while suppressing the schema validation. It works, but it's worth being aware that you're partially opting out rather than fully.

That said, I understand the friction. If the schema validation error could distinguish between "no constraint exists" and "no constraint is expected," that might be a cleaner place to add flexibility without compromising the model design. Happy to discuss further.