ALTER CURRENT GRAPH TYPE

Generic Description

Replace or incrementally change the type definition bound to the current graph.

Simple example:

ALTER CURRENT GRAPH TYPE ADD { (:Movie { title STRING }) }

Consumer-Level Explanation

Use this when you need to tell Nexyron what kinds of nodes and edges the current graph is expected to contain, or when that graph shape needs to evolve over time.

Conceptual Explanation

ALTER CURRENT GRAPH TYPE is not a data-mutation clause. It changes the graph-type contract for the currently bound graph. The parser supports three operational modes:

• SET { ... }: replace the full current graph-type definition
• ADD { ... }: extend the current graph type with new node or edge types
• DROP { ... }: remove node or edge types from the current graph type

This matters when teams want explicit graph-shape governance rather than relying only on emergent labels and properties.

More Detailed Explanation

The important conceptual distinction is between changing graph data and changing the graph's declared type shape.

Examples of where this matters:

• a platform adds a new node type such as :Movie or :Policy
• a relationship type gains enough importance to become part of the formal graph contract
• a migration removes a legacy edge type that should no longer appear in the graph

The parser maps SET to a replace-style graph-type creation for the current graph, while ADD and DROP become explicit graph-type alterations.

Advanced Example

This example keeps ALTER CURRENT GRAPH TYPE as the focal statement while showing the kind of system where graph, time, document-style metadata, and vector features coexist around the same graph contract.

ALTER CURRENT GRAPH TYPE ADD {
  (:Incident {
    title STRING NOT NULL,
    severity STRING,
    metadata MAP,
    embedding LIST
  }),
  (:Service)-[:IMPACTS { ts DATETIME, payload MAP }]->(:Incident)
}

After a change like this, teams can issue queries that combine:

• graph traversal from Service to Incident
• event-time filtering on IMPACTS.ts
• document-style inspection of payload or metadata
• vector similarity against embedding

Real Use Cases

• Formalizing new domain entities as a product expands into new graph-driven features.
• Tightening graph governance for regulated or multi-team environments where implicit schema drift is risky.
• Removing obsolete types during a controlled migration instead of letting old shapes linger indefinitely.

Real Limitations And Tradeoffs

• A declared graph type does not automatically rewrite existing data to match the new shape.
• Overly rigid graph typing can slow down exploratory modeling if teams are still learning the domain.
• Replacing the entire graph type with SET is more disruptive than a narrowly scoped ADD or DROP.