mammoth-cli 2.2.11__tar.gz → 2.2.12__tar.gz

{mammoth_cli-2.2.11 → mammoth_cli-2.2.12}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mammoth-cli
-Version: 2.2.11
+Version: 2.2.12
 Summary: Command-line interface for the Mammoth Analytics platform
 Project-URL: homepage, https://mammoth.io
 Project-URL: repository, https://github.com/EdgeMetric/mammothsdk

{mammoth_cli-2.2.11 → mammoth_cli-2.2.12}/mammoth_cli/__init__.py

@@ -6,7 +6,7 @@ not implement a second HTTP client and does not call private SDK members.
 
 from __future__ import annotations
 
-__version__ = "2.2.11"
+__version__ = "2.2.12"
 
 # The versioned machine output envelope contract.
 SCHEMA_VERSION = 1

{mammoth_cli-2.2.11 → mammoth_cli-2.2.12}/mammoth_cli/bundled_skill/mammoth-cli/references/commands/view.md

@@ -160,7 +160,7 @@ Example: `mammoth view create 123`. Placeholders are illustrative; resolve IDs a
 
 Result: `ViewCreateResult`; mutation `benign_mutation`, confirmation `none`, wait policy `always_wait`.
 
-Status on release: ran once on CLI 2.0.18 — golden-data check 2026-09-19 (CLI 2.0.18): plain create on an owned dataset returned the new view's record (id, dataset_id; earlier releases printed '<unserializable View>'), and discard-duplicates then ran on it. clone_from is not usable on release: the clon…
+Status on release: ran once on CLI 2.0.18 — golden-data check 2026-09-19 (CLI 2.0.18): plain create on an owned dataset returned the new view's record (id, dataset_id; earlier releases printed '<unserializable View>'), and discard-duplicates then ran on it. clone_from works on a backend with mvc e56f23…
 
 ### `view.data-check.create`
 

{mammoth_cli-2.2.11 → mammoth_cli-2.2.12}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/end-to-end.md

@@ -56,8 +56,8 @@ mammoth view export csv ORDERS_VIEW --project PROJECT_ID \
 #   check the file's header and row count against the last readback
 
 # 7. per-region summary as the LAST step on the same view (pivot replaces the view's columns in place;
-#    do not use view create with clone_from for this: on release the clone job succeeds but the copy
-#    answers every read with 4DTVW019 and its copied tasks never execute)
+#    to keep the uncollapsed view as well, copy it first with view create DATASET_ID --input '{"clone_from": VIEW_ID}'
+#    (same dataset only; the copy keeps the source's steps) and pivot the copy instead)
 mammoth view transform pivot ORDERS_VIEW --project PROJECT_ID \
   --input '{"dataset_id": ORDERS_DS, "group_by": ["region"], "aggregations": [{"column": "amount", "function": "SUM", "as_name": "total_amount"}, {"column": "order_id", "function": "COUNT", "as_name": "order_count"}]}'
 mammoth view data get ORDERS_VIEW ORDERS_DS --project PROJECT_ID

{mammoth_cli-2.2.11 → mammoth_cli-2.2.12}/mammoth_cli/bundled_skill/mammoth-cli/references/recipes/transforms.md

@@ -151,11 +151,15 @@ display name) with display-name columns; unquoted or placeholder table names
 select queries allowed". The result replaces the view's columns: never run it
 (or `pivot`) on a view whose rows are still needed; export those rows first
 (`view export csv`) and run the summary as the last step, and prefer `pivot`
-(proven on release) over a SQL task. Do not build the summary on a
-`view create ... "clone_from": VIEW_ID` copy: on release the clone job succeeds
-but the copy answers every read with `4DTVW019` and its copied tasks never
-execute. A plain `view create DATASET_ID` (no `clone_from`) gives a fresh view
-of the raw upload, without the pipeline:
+(proven on release) over a SQL task. To keep the view's rows and still
+summarise, copy it first with `view create DATASET_ID --input
+'{"clone_from": VIEW_ID}'` (same dataset only) and run the summary on the
+copy: the copy keeps the source's steps and runs them (koyal, 2026-10-02: the
+cloned steps executed and the copy took a further filter). Only a backend
+older than 2026-09-26 left the copy's tasks unrun, answering reads with
+`4DTVW019`; see recovery.md. A plain `view create DATASET_ID` (no
+`clone_from`) is not a copy: it gives a fresh view of the raw upload, without
+the pipeline:
 
 A task must fit the column's type: `replace-values`, `bulk-replace` and the
 text operations take TEXT columns, `math` takes NUMERIC. Check `type` in the

{mammoth_cli-2.2.11 → mammoth_cli-2.2.12}/mammoth_cli/bundled_skill/mammoth-cli/references/recovery.md

@@ -30,7 +30,7 @@ these commands are not blanket permission to replay a mutation.
 | `resource_not_found` (exit 5) after `view get VIEW_ID` / `view data get VIEW_ID` without a parent | discovery could not find the view in the selected project | pass `--project PROJECT_ID` and the `DATASET_ID` positional from `view list` |
 | `{"data": "<unserializable View>"}` from `view get VIEW_ID` | CLI ≤ 2.0.17 only; fixed in 2.0.18 | upgrade, or rerun as `view get VIEW_ID DATASET_ID` |
 | `pipeline_reference_error` (exit 1) from a transform or `view task add`, `details.reference_errors[].reason` `type mismatch` / `not available` | the backend stored the task but cannot bind it to that column (find/replace and text operations take TEXT columns, math takes NUMERIC); the view is in `ref_error` and every read of it fails with `4DTVW019` until the task goes | run the printed `view task delete VIEW_ID TASK_ID --yes`, then convert-type the column or pick a transform for its type; CLI ≤ 2.0.24 reported this as success with `has_error: true` |
-| `4DTVW019 INVALID_RESPONSE_GENERATED` on every read of a view made with `view create ... "clone_from"` | backend: the clone is never processed (tasks stay `added`) | delete the copy; export the source view's rows, then run the summary in place as the last step; see recipes/end-to-end.md |
+| `4DTVW019 INVALID_RESPONSE_GENERATED` on every read of a view made with `view create ... "clone_from"` | only a backend older than mvc `e56f2338b6` (2026-09-26) leaves the clone's copied tasks `added`, never run; on a current backend a same-dataset clone runs its copied tasks and reads normally (koyal view 4429: both tasks `executed`), so any other cause is the `ref_error` row above | `view task list VIEW_ID DATASET_ID`: tasks stuck at `added` mean an old backend, so delete the copy and rebuild the steps on a plain view; a task in `ref_error` means delete that task. A copy of a view should still be made with `clone_from` (same dataset only), which keeps the source's steps; see recipes/end-to-end.md |
 | `needs_view` in `file upload` result, or `status: ready` with `status_info.ready` "more than one plausible way to be read" and `view list` empty | all-text CSV: the platform ingests the rows but creates no view | run the `next_command` (`view create DATASET_ID`) once, then `view list DATASET_ID`; see recipes/need-action.md |
 | `need_action` in `file upload` result | the platform needs a parsing decision (e.g. ambiguous dates) | run the `next_command` it returns (`dataset file-settings get ID`), then `dataset file-settings update ID`; see recipes/need-action.md |
 | `confirmation_required` (exit 2) | destructive/high-impact command without `--yes` (and `--confirm TARGET` when policy is confirm_target) | re-run with the flag after you have read the target back by id |

{mammoth_cli-2.2.11 → mammoth_cli-2.2.12}/mammoth_cli/services/listing.py

@@ -158,7 +158,7 @@ def ambiguity_note(matched: int, needle: str) -> str | None:
         return None
     return (
         f"{matched} datasets match '{needle}' (a v2 or a copy can sit beside the one meant): "
-        "pick by id from rows/cols/created, and name the dataset you read in your answer."
+        "if nothing in the request tells them apart, ask the user which one before reading any."
     )
 
 

{mammoth_cli-2.2.11 → mammoth_cli-2.2.12}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "mammoth-cli"
-version = "2.2.11"
+version = "2.2.12"
 description = "Command-line interface for the Mammoth Analytics platform"
 authors = [{name = "Mammoth Analytics", email = "support@mammoth.io"}]
 readme = "README.md"