yarramate 1.1.0 → 1.3.0

package/dist/relationship-drafting.d.ts

@@ -33,8 +33,16 @@ export declare const connectableKinds: (graph: CanvasGraph, fromId: string, toId
  * relationship kind is a single lowercase word. A collision takes a numeric
  * suffix rather than a hash, because the id is authored text a human will read
  * in a diff.
+ *
+ * `reserved` carries ids the graph does not know yet: a staged-but-uncommitted
+ * draft never enters the rendered graph, so without it a second relationship
+ * between the same pair re-proposed the identical id and the editor's
+ * replace-by-target staging silently swallowed the first (#306). The schema
+ * places no uniqueness on the (from, kind, to) triple - parallel relationships
+ * with distinct ids compile cleanly - so the id proposal is the only place the
+ * collision can be stepped past.
  */
-export declare const proposeRelationshipId: (graph: CanvasGraph, fromId: string, kind: RelationshipKind, toId: string) => string;
+export declare const proposeRelationshipId: (graph: CanvasGraph, fromId: string, kind: RelationshipKind, toId: string, reserved?: Iterable<string>) => string;
 /**
  * The operation that lands a drafted relationship, or `null` when the draft is
  * one the table does not permit.
@@ -47,5 +55,16 @@ export declare const proposeRelationshipId: (graph: CanvasGraph, fromId: string,
  * relationship has to live somewhere, both endpoints are equally defensible,
  * and the source is where a reader looking for what this thing does would go
  * first.
+ *
+ * A caller holding drafts the graph has not landed yet - an editor with a
+ * pending changeset - passes their ids as `reserved`, so a second parallel
+ * relationship steps to `-2` instead of colliding with the first (#306).
+ */
+export declare const draftRelationship: (graph: CanvasGraph, fromId: string, kind: RelationshipKind, toId: string, reserved?: Iterable<string>) => YarramateOperation | null;
+/**
+ * The ids a pending changeset already claims, for `proposeRelationshipId`'s
+ * `reserved` parameter. Every operation that names a subject id reserves it -
+ * an update's id is already in the graph and reserving it twice is harmless,
+ * while an add's id is exactly the one the graph cannot know yet.
  */
-export declare const draftRelationship: (graph: CanvasGraph, fromId: string, kind: RelationshipKind, toId: string) => YarramateOperation | null;
+export declare const stagedSubjectIds: (operations: readonly YarramateOperation[]) => readonly string[];

package/dist/relationship-drafting.js

@@ -45,11 +45,20 @@ export const connectableKinds = (graph, fromId, toId) => {
  * relationship kind is a single lowercase word. A collision takes a numeric
  * suffix rather than a hash, because the id is authored text a human will read
  * in a diff.
+ *
+ * `reserved` carries ids the graph does not know yet: a staged-but-uncommitted
+ * draft never enters the rendered graph, so without it a second relationship
+ * between the same pair re-proposed the identical id and the editor's
+ * replace-by-target staging silently swallowed the first (#306). The schema
+ * places no uniqueness on the (from, kind, to) triple - parallel relationships
+ * with distinct ids compile cleanly - so the id proposal is the only place the
+ * collision can be stepped past.
  */
-export const proposeRelationshipId = (graph, fromId, kind, toId) => {
+export const proposeRelationshipId = (graph, fromId, kind, toId, reserved = []) => {
     const taken = new Set([
         ...graph.nodes.map((node) => node.id),
         ...graph.edges.map((edge) => edge.id),
+        ...reserved,
     ]);
     const base = `${fromId}-${kind}-${toId}`;
     if (!taken.has(base))
@@ -72,8 +81,12 @@ export const proposeRelationshipId = (graph, fromId, kind, toId) => {
  * relationship has to live somewhere, both endpoints are equally defensible,
  * and the source is where a reader looking for what this thing does would go
  * first.
+ *
+ * A caller holding drafts the graph has not landed yet - an editor with a
+ * pending changeset - passes their ids as `reserved`, so a second parallel
+ * relationship steps to `-2` instead of colliding with the first (#306).
  */
-export const draftRelationship = (graph, fromId, kind, toId) => {
+export const draftRelationship = (graph, fromId, kind, toId, reserved = []) => {
     if (!connectableKinds(graph, fromId, toId).includes(kind))
         return null;
     const from = graph.nodes.find((node) => node.id === fromId);
@@ -83,10 +96,27 @@ export const draftRelationship = (graph, fromId, kind, toId) => {
         op: 'add-relationship',
         document: from.document,
         relationship: {
-            id: proposeRelationshipId(graph, fromId, kind, toId),
+            id: proposeRelationshipId(graph, fromId, kind, toId, reserved),
             kind,
             from: fromId,
             to: toId,
         },
     };
 };
+/**
+ * The ids a pending changeset already claims, for `proposeRelationshipId`'s
+ * `reserved` parameter. Every operation that names a subject id reserves it -
+ * an update's id is already in the graph and reserving it twice is harmless,
+ * while an add's id is exactly the one the graph cannot know yet.
+ */
+export const stagedSubjectIds = (operations) => operations.flatMap((op) => {
+    // A staged rename claims the id it moves to as well as the one it leaves.
+    const renamedTo = op.op === 'rename-concept' || op.op === 'rename-relationship'
+        ? [op.to]
+        : [];
+    if ('relationship' in op)
+        return [op.relationship.id, ...renamedTo];
+    if ('concept' in op)
+        return [op.concept.id, ...renamedTo];
+    return renamedTo;
+});

package/dist/subject-references.js

@@ -56,6 +56,11 @@ export const SUBJECT_REFERENCE_POSITIONS = [
         path: ['query', 'subjects', '*'],
         form: 'qualified',
     },
+    {
+        group: 'projection',
+        path: ['query', 'exclude', '*'],
+        form: 'qualified',
+    },
     { group: 'projection', path: ['query', 'owners', '*'], form: 'qualified' },
     {
         group: 'projection',