SG Ground Truth

summarize multi grouping

_summarize nests one group level per grouping entry, 3 deep tested, counts summing exactly. status_list rolls a group up to one status; status_percentage ignores any value and is no per-status share.

API

Q Does _summarize nest two grouping entries, and what do status_percentage and status_list return on sg_status_list?

Endpoint POST /entity/<type>/_summarize

Docs claim Grouping takes a list. Silent on nesting and on what the status types compute.

Actual

Shots grouped [sg_sequence, sg_status_list] -> 200, 15 groups, total {"id": 300}
  {"group_name": "seq01", "group_value": {"type": "Sequence", "id": <id>, "name": "seq01", "valid": "valid"},
   "summaries": {"id": 20}, "groups": [{"group_name": "wtg", "group_value": "wtg", "summaries": {"id": 3}},
                                        {"group_name": "ip", "group_value": "ip", "summaries": {"id": 8}}, ...]}
  each parent's count equals the sum of its children: True
Tasks grouped [entity, step, sg_status_list] -> 200, nesting depth 3
Tasks grouped on entity.Shot.sg_sequence -> 200, 16 groups; on start_date by week -> 200, 19 groups
bogus grouping type -> 400 "type must be one of: exact, tens, hundreds, thousands, tensofthousands,
  hundredsofthousands, millions, day, week, month, quarter, year, clustered_date, oneday, fivedays,
  entitytype, firstletter"

status_percentage over the project, then per status group (value, rows, status_percentage):
  shots     0 over 300    [(wtg, 183, 0), (ip, 64, 0), (fin, 53, 0)]
  tasks     3 over 1900   [(wtg, 851, 0), (ip, 139, 0), (fin, 844, 0), (apr, 4, 0), (null, 62, 0)]
  versions  0 over 100    [(na, 28, -1), (rev, 29, 0), (vwd, 21, 0), (apr, 20, 0), (fin, 2, 0)]
  status_percentage_as_float: 0, 3, 0, the same integers
  shots with "value": "fin", "values": ["fin"] or "status": "fin" -> 200 {"sg_status_list": 0}
status_list per group, against the statuses in it:
  [wtg] -> wtg   [fin] -> fin   [ip, wtg] -> ip   [fin, ip] -> ip   [fin, ip, wtg] -> ip
  [null, fin, wtg] -> ip   ... 12 distinct pairs over the Tasks, every mixed set -> ip

Teaches

  • Nested groups are one call. Each grouping entry adds a level: a group holds groups with the next field's groups, and the leaf level has no groups key. Group headers for a page grouped two or three deep cost one _summarize, not a page of rows. Grouping takes a dotted path and the date buckets the web interface stores (week, probe 073).
  • status_list is the roll-up. One status alone rolls up to itself; any mix rolls up to ip, even [null, fin, wtg] where no row is ip. On the probed site that is the rule on every group measured. It honours a field's excluded statuses (probe 091).
  • status_percentage does not answer "what share is fin". It ignores value and every other key sent, returns an integer under both names, and gave 3 on Tasks where 62 of 1900 rows (3.3%) have no status and -1 on a group of na Versions. Compute a status share yourself from one grouped count: rows in status / rows in group.
  • The page grid summary {"type": "status_percentage", "value": "fin"} (probe 073) is therefore not a _summarize call; reproduce it from the grouping on sg_status_list.

Every entry on this site is the output of a probe in probes/. The corpus is generated by running those probes against a live Flow Production Tracking site, not written from memory.

Not affiliated with or endorsed by Autodesk. Flow Production Tracking is their product; this is an independent record of how its REST API answers.