Similar.
I've been thinking about rewriting queries like this to consolidate them (and be somewhat more efficient) when they can be.
This works with "authors" because no two events can match the same author, but it doesn't work for other queries.
For example, [..., {"#p": ["a", "b"]] and [..., {"#p": ["a"]}, {"#p": ["b"]}] are not quite the same.
scsibug (npub1xhf…4xw3) you are probably getting away with UNION in these cases and letting db engine do the de-duplicating for you.
But once you implement cursor/"pagination" of queries, leaning on UNION for deduplication won't work.
I'm doing pagination/cursor-based query results now, which means you might get duplicate events in some cases for a separated "#p" query like that.
However, once I implement query rewriting this will be partially fixed by rewriting [..., {"#p": ["a"]}, {"#p": ["b"]}] to [..., {"#p": ["a", "b"]], which will be more efficient and naturally produce non-duplicate results.
For query filters that can't be consolidated -- e.g., [..., {"#p": ["a"]}, {"#p": ["b"], "authors": ["dead"]}}] -- deduplication is kinda tricky and not ideal, so will have to figure that out at some point or live with it.
aaron / A. A. RON
npub14l…37m8m
2023-01-25 22:00:44
in reply to nevent1q…26tx
Author Public Key
npub14lu6nuqh7v4jazmqw49yzqkmnkw0nletjeuqfdgwqurcp2j9ex5qz37m8mPublished at
2023-01-25 22:00:44Event JSON
{
"id": "2f6cbcad481ba0212d7559861b7ebf34ef35e23b8ffd9eabf646196045f95c63",
"pubkey": "aff9a9f017f32b2e8b60754a4102db9d9cf9ff2b967804b50e070780aa45c9a8",
"created_at": 1674684044,
"kind": 1,
"tags": [
[
"e",
"a1381dbdde7095de13b186fd942e1bf3c82f553bc4ff0658dfe6d91625024b9e",
"",
"root"
],
[
"e",
"fc535eb45fd37bea9ca2b3daa52830a46621913a2b707faed58b76864b9dd02b",
"",
"reply"
],
[
"p",
"35d26e4690cbe1a898af61cc3515661eb5fa763b57bd0b42e45099c8b32fd50f"
],
[
"p",
"00000000827ffaa94bfea288c3dfce4422c794fbb96625b6b31e9049f729d700"
],
[
"p",
"35d26e4690cbe1a898af61cc3515661eb5fa763b57bd0b42e45099c8b32fd50f"
],
[
"p",
"3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
],
[
"p",
"35d26e4690cbe1a898af61cc3515661eb5fa763b57bd0b42e45099c8b32fd50f"
],
[
"t",
"p"
]
],
"content": "Similar.\n\nI've been thinking about rewriting queries like this to consolidate them (and be somewhat more efficient) when they can be. \n\nThis works with \"authors\" because no two events can match the same author, but it doesn't work for other queries. \n\nFor example, [..., {\"#p\": [\"a\", \"b\"]] and [..., {\"#p\": [\"a\"]}, {\"#p\": [\"b\"]}] are not quite the same.\n\n#[6] you are probably getting away with UNION in these cases and letting db engine do the de-duplicating for you.\n\nBut once you implement cursor/\"pagination\" of queries, leaning on UNION for deduplication won't work.\n\nI'm doing pagination/cursor-based query results now, which means you might get duplicate events in some cases for a separated \"#p\" query like that.\n\nHowever, once I implement query rewriting this will be partially fixed by rewriting [..., {\"#p\": [\"a\"]}, {\"#p\": [\"b\"]}] to [..., {\"#p\": [\"a\", \"b\"]], which will be more efficient and naturally produce non-duplicate results.\n\nFor query filters that can't be consolidated -- e.g., [..., {\"#p\": [\"a\"]}, {\"#p\": [\"b\"], \"authors\": [\"dead\"]}}] -- deduplication is kinda tricky and not ideal, so will have to figure that out at some point or live with it.\n\n\n",
"sig": "02e2f9163674a7032d95bb6797fccb67775638d27b6e9deaab8ff3d313693fd2064c6e739252574052f2881a2c4b6769e1e84dfbaee7b7a202ebb046ef1e2058"
}