IFC-1245 Initial implementation for object templates

[gmazoyer]

This is the initial implementation of object templates.

An object template is a schema node that is generated on the fly when a node defines generate_template: true. When generating object template schema, the schema manager will traverse parent/component relationships in order to determine which templates are required.

Nodes for which templates are generated will automatically get a object_template relationship pointing to the template that was used to create the objects. Templates will also have a related_nodes relationship with references to objects created by templates.

Templates have their own namespace and are published in the REST API schema under the templates key.

When running a GraphQL mutation, if an object_template relationship is specified, attributes from the template will be applied as the ones of the object to create. Attributes with values given in the mutation input will still prevail over the ones of the template.

When creating an object, parent/component relationships are resolved and objects will also be created. This is done in 2 steps: it first creates the initial object which is based on the given template, then it goes through relationships and populates them.

Relationships of other kinds are not yet supported but can be implemented at the next step of this feature implementation.

[codspeed-hq]

CodSpeed Performance Report

Merging #5610 will not alter performance

_{Comparing gma-20250129-ifc1177 (f9aa039) with develop (6244a9d)}

Summary

✅ 11 untouched benchmarks

[ogenstad]

Adding some minor comments for now, will look more later.

[ogenstad]

We should add this to the release notes to indicate that we're adding a new namespace to the list of restricted ones.

[ogenstad]

Nitpicking here but for the count and query methods when we are updating them we might as well get rid of the Union.

[LucasG0]

Should it be kind instead of name? Same for SchemaBranch.get?

[gmazoyer]

I used the same parameter name as all the methods that perform the same kind of operations. I agree that name is not the best name for it, I used it for consistency reasons. I guess we could rename that parameter for all the methods in another PR.

[ogenstad]

Nice work! Looks good to me overall. I left some comments, the most important one would be related to the scenario if we can't find the template during the processing of a node.

[ogenstad]

I wonder if we should have a common name for NodeSchema | ProfileSchema | TemplateSchema in the same we we have for MainSchemaTypes.

[ogenstad]

When saving the peer here we would have a changelog for that peer under obj_peer.node_changelog I think we'd want the .handle_relationships() method to send back a list[NodeChangelog] to the caller in order to get a full picture of what has changed.

[ajtmccarty]

could you do something like this instead

object_template = await cls.get_object_template(db=db, branch=branch, obj=obj, data=data)
if object_template:
    await cls._handle_template_relationships(
        db=db,
        branch=branch,
        constraint_runner=node_constraint_runner,
        template=object_template,
        obj=obj
    )

seems like _handle_object_template is basically getting an object template and then running it through _handle_relationships and _handle_relationships doesn't need to get its own version of NodeConstraintRunner this way

[gmazoyer]

That node constraint runner setup bugs me as well. When I tried to use the existing one, built by the mutation code, it failed at identifying the original node (Unable to find the node X / KIND error). My guess is that it does not play very well with a performance fix we pushed earlier this week.

[gmazoyer]

After giving this some thoughts I wonder if it is going to be an issue with relationships allocated from pool, if they are also used in uniqueness constraints.