Thanks Dan, your branch is a great improvement. I think I can also see what's going on in Tina's examples too. The Source Path separator is different between the XUL and web clients: The XUL Client uses both '->' and '::' depending on how many layers down the tree you go, while the Web Client instead only uses '->' regardless of the number of links traversed. So when you clone a simple XUL report that results in this SQL:
SELECT "67bf5c5e1a824cdc5d44508d00cf2ff7"."barcode" AS "Barcode",
COUNT(DISTINCT "e443e095dd88083d1a9da7e3630b7185"."id") AS "Use ID",
"076bf6f3642cbc96b197e17f5bc8943e"."circ_count" AS "Total Circulation Count"
FROM action.in_house_use AS "e443e095dd88083d1a9da7e3630b7185"
RIGHT OUTER JOIN asset.copy AS "67bf5c5e1a824cdc5d44508d00cf2ff7" ON ("e443e095dd88083d1a9da7e3630b7185"."item" = "67bf5c5e1a824cdc5d44508d00cf2ff7"."id")
FULL OUTER JOIN extend_reporter.full_circ_count AS "076bf6f3642cbc96b197e17f5bc8943e" ON ("67bf5c5e1a824cdc5d44508d00cf2ff7"."id" = "076bf6f3642cbc96b197e17f5bc8943e"."id")
WHERE "67bf5c5e1a824cdc5d44508d00cf2ff7"."circ_lib" IN ($_15939$335$_15939$)
GROUP BY 1, 3, 4
ORDER BY "67bf5c5e1a824cdc5d44508d00cf2ff7"."barcode" ASC, COUNT(DISTINCT "e443e095dd88083d1a9da7e3630b7185"."id") ASC, "076bf6f3642cbc96b197e17f5bc8943e"."circ_count" ASC
in the web client and try to add the Active Date field (following the same right join path, as expected) you'll still end up with something like this:
SELECT "67bf5c5e1a824cdc5d44508d00cf2ff7"."barcode" AS "Barcode",
COUNT(DISTINCT "e443e095dd88083d1a9da7e3630b7185"."id") AS "Use ID",
"076bf6f3642cbc96b197e17f5bc8943e"."circ_count" AS "Total Circulation Count",
"92632112b9e5a769d2fa4b1c967657f5"."active_date" AS "Active Date/Time"
FROM action.in_house_use AS "e443e095dd88083d1a9da7e3630b7185"
RIGHT OUTER JOIN asset.copy AS "67bf5c5e1a824cdc5d44508d00cf2ff7" ON ("e443e095dd88083d1a9da7e3630b7185"."item" = "67bf5c5e1a824cdc5d44508d00cf2ff7"."id")
FULL OUTER JOIN extend_reporter.full_circ_count AS "076bf6f3642cbc96b197e17f5bc8943e" ON ("67bf5c5e1a824cdc5d44508d00cf2ff7"."id" = "076bf6f3642cbc96b197e17f5bc8943e"."id")
WHERE "67bf5c5e1a824cdc5d44508d00cf2ff7"."circ_lib" IN ($_2397$335$_2397$)
GROUP BY 1, 3, 4
ORDER BY "67bf5c5e1a824cdc5d44508d00cf2ff7"."barcode" ASC, COUNT(DISTINCT "e443e095dd88083d1a9da7e3630b7185"."id") ASC, "076bf6f3642cbc96b197e17f5bc8943e"."circ_count" ASC, "92632112b9e5a769d2fa4b1c967657f5"."active_date" ASC
Where the hash "92632112b9e5a769d2fa4b1c967657f5" is assumed to be the same path as hash "67bf5c5e1a824cdc5d44508d00cf2ff7" (because it is, except for the difference in separators) and so isn't defined anywhere, leading to a FROM clause complaint.
This leads to a situation where it's possible to clone a XUL report and manipulate it in the web client, but actually adding new fields to the reports is highly unlikely to ever succeed.
I'm open to suggestions on how to proceed here, should there be a key dropped in the JSON that triggers the old "source -> path :: path" style of source specifier for reports of that era, or should all of the hashes be re-generated every time a report is saved (I haven't checked the format to see if that even makes sense), or should the web client reporter just be changed to match the old format (do not want), or something else?
Thanks Dan, your branch is a great improvement. I think I can also see what's going on in Tina's examples too. The Source Path separator is different between the XUL and web clients: The XUL Client uses both '->' and '::' depending on how many layers down the tree you go, while the Web Client instead only uses '->' regardless of the number of links traversed. So when you clone a simple XUL report that results in this SQL:
SELECT "67bf5c5e1a824c dc5d44508d00cf2 ff7"."barcode" AS "Barcode", 3d1a9da7e3630b7 185"."id" ) AS "Use ID", 2cbc96b197e17f5 bc8943e" ."circ_ count" AS "Total Circulation Count" 3d1a9da7e3630b7 185" dc5d44508d00cf2 ff7" ON ("e443e095dd880 83d1a9da7e3630b 7185"." item" = "67bf5c5e1a824c dc5d44508d00cf2 ff7"."id" ) reporter. full_circ_ count AS "076bf6f3642cbc 96b197e17f5bc89 43e" ON ("67bf5c5e1a824 cdc5d44508d00cf 2ff7"." id" = "076bf6f3642cbc 96b197e17f5bc89 43e"."id" ) dc5d44508d00cf2 ff7"."circ_ lib" IN ($_15939$ 335$_15939$ ) dc5d44508d00cf2 ff7"."barcode" ASC, COUNT(DISTINCT "e443e095dd8808 3d1a9da7e3630b7 185"."id" ) ASC, "076bf6f3642cbc 96b197e17f5bc89 43e"."circ_ count" ASC
COUNT(DISTINCT "e443e095dd8808
"076bf6f364
FROM action.in_house_use AS "e443e095dd8808
RIGHT OUTER JOIN asset.copy AS "67bf5c5e1a824c
FULL OUTER JOIN extend_
WHERE "67bf5c5e1a824c
GROUP BY 1, 3, 4
ORDER BY "67bf5c5e1a824c
in the web client and try to add the Active Date field (following the same right join path, as expected) you'll still end up with something like this:
SELECT "67bf5c5e1a824c dc5d44508d00cf2 ff7"."barcode" AS "Barcode", 3d1a9da7e3630b7 185"."id" ) AS "Use ID", 2cbc96b197e17f5 bc8943e" ."circ_ count" AS "Total Circulation Count", e5a769d2fa4b1c9 67657f5" ."active_ date" AS "Active Date/Time" 3d1a9da7e3630b7 185" dc5d44508d00cf2 ff7" ON ("e443e095dd880 83d1a9da7e3630b 7185"." item" = "67bf5c5e1a824c dc5d44508d00cf2 ff7"."id" ) reporter. full_circ_ count AS "076bf6f3642cbc 96b197e17f5bc89 43e" ON ("67bf5c5e1a824 cdc5d44508d00cf 2ff7"." id" = "076bf6f3642cbc 96b197e17f5bc89 43e"."id" ) dc5d44508d00cf2 ff7"."circ_ lib" IN ($_2397$335$_2397$) dc5d44508d00cf2 ff7"."barcode" ASC, COUNT(DISTINCT "e443e095dd8808 3d1a9da7e3630b7 185"."id" ) ASC, "076bf6f3642cbc 96b197e17f5bc89 43e"."circ_ count" ASC, "92632112b9e5a7 69d2fa4b1c96765 7f5"."active_ date" ASC
COUNT(DISTINCT "e443e095dd8808
"076bf6f364
"92632112b9
FROM action.in_house_use AS "e443e095dd8808
RIGHT OUTER JOIN asset.copy AS "67bf5c5e1a824c
FULL OUTER JOIN extend_
WHERE "67bf5c5e1a824c
GROUP BY 1, 3, 4
ORDER BY "67bf5c5e1a824c
Where the hash "92632112b9e5a7 69d2fa4b1c96765 7f5" is assumed to be the same path as hash "67bf5c5e1a824c dc5d44508d00cf2 ff7" (because it is, except for the difference in separators) and so isn't defined anywhere, leading to a FROM clause complaint.
This leads to a situation where it's possible to clone a XUL report and manipulate it in the web client, but actually adding new fields to the reports is highly unlikely to ever succeed.
I'm open to suggestions on how to proceed here, should there be a key dropped in the JSON that triggers the old "source -> path :: path" style of source specifier for reports of that era, or should all of the hashes be re-generated every time a report is saved (I haven't checked the format to see if that even makes sense), or should the web client reporter just be changed to match the old format (do not want), or something else?