diff --git a/src/packages/dlayer/cursor.js b/src/packages/dlayer/cursor.js index a75d150..e41d22d 100644 --- a/src/packages/dlayer/cursor.js +++ b/src/packages/dlayer/cursor.js @@ -3,7 +3,6 @@ // 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 function createInstance({ queryPath, schemaPath, queryObject, schemaObject }) { - console.log("create", { queryPath, schemaPath, queryObject, schemaObject }); return { queryPath: queryPath, schemaPath: schemaPath, diff --git a/src/packages/dlayer/index.js b/src/packages/dlayer/index.js index b164df7..bbd112e 100644 --- a/src/packages/dlayer/index.js +++ b/src/packages/dlayer/index.js @@ -128,8 +128,7 @@ function evaluate(cursor, context) { return mapMaybeArray(value, (item, i) => { // 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}); + // TODO: 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? let subCursor = (i != null) ? cursor .child(queryKey, schemaKey)