There is a case in which a schema does not have its own primary key. Instead, it uses two secondary indices as key. For example:
export const Edge = z.object({
type: z.string().optional(),
sourceId: z.string().describe("index"),
targetId: z.string().describe("index"),
});Right now pentagon store the edge in two keys ["edges_by_sourceId", sourceId] and ["edges_by_targetId", targetId]. This is not ideal because querying on these relations are not what one would expect. For example, with a Node schema like below:
export const Node = z.object({
id: z.string().describe("primary, unique"),
name: z.string().optional(),
});To query edges starting out from a Node, one would need to define the relation like so:
nodes: {
schema: Node,
relations: {
edges: ["edges_by_sourceId", [Edge], undefined, "sourceId"],
},
},
Even so, other queries do not seem to work well.
I looked at Prisma, and it looks like they support composite primary keys. This may work nicely with Deno.KV if we use ["edges", sourceId, targetId] as key.
Not sure how to implement such a thing, but it's an idea.
There is a case in which a schema does not have its own primary key. Instead, it uses two secondary indices as key. For example:
Right now
pentagonstore the edge in two keys["edges_by_sourceId", sourceId]and["edges_by_targetId", targetId]. This is not ideal because querying on these relations are not what one would expect. For example, with a Node schema like below:To query edges starting out from a Node, one would need to define the relation like so:
Even so, other queries do not seem to work well.
I looked at Prisma, and it looks like they support composite primary keys. This may work nicely with Deno.KV if we use
["edges", sourceId, targetId]as key.Not sure how to implement such a thing, but it's an idea.