// Simple data type to represent a query path and corresponding schema path tied together, because these are basically always used together, and it would bloat up the implementation code otherwise
// TODO: Maybe clean up all the .child stuff here by moving the `$key` logic into the cursor implementation instead, as it seems like nothing else in dlayer needs to care about the aliasing
// When constructing the result object, we only care about the 'real' keys, not about special meta-keys like $key; those get processed in the actual resolution logic itself.
// NOTE: We're adding `i` to the query path for user feedback purposes, but we're not *actually* diving down into that property on the query object; the queryOverride doesn't just handle recursion, it also ensures that the 'original' subquery is passed in regardless of what the path suggests
// NOTE: schemaOverride here is used to pass in the (asynchronously/lazily) resolved result, which the cursor implementation wouldn't have access to otherwise; need to somehow make it clearer in the API design that the automatic 'schema navigation' is only used for simple objects - maybe not call it an 'override' but instead just something like newSchema and newQuery?
console.log({queryKey,schemaKey});
letsubCursor=(i!=null)
?cursor
.child(queryKey,schemaKey)
.child(i,i,{
queryOverride:effectiveSubquery,
schemaOverride:item
})
:cursor
.child(queryKey,schemaKey,{
queryOverride:effectiveSubquery,
schemaOverride:item
});
returnevaluate(subCursor,context);
});
}else{
// null / undefined are returned as-is, so are leaves