[01:57:42] * ebernhardson wonders if deduplicatable is too awkward....probably :P [02:27:34] the more i think about this deduplication...now i'm wondering why we can't just emit the last event of the window [02:28:06] We only have two possible actions: delete the page, replace the page with current cirrusdoc. These are inverses of each other, so it never makes sense to emit more than one [02:29:06] which one wins? I can't come up with any reasonable answer other than the one with the most recent timestamp [05:15:35] @in.flatador: Re-image of 2021 looks happy. I set a downtime on the host. Haven't kicked off the data transfer; we should get that going tomorrow morning from 2022->2021 [08:18:31] ebernhardson: indeed, on the same rev_id I don't see other ways to discriminate than using the event time [08:19:20] and indeed "deduplicatable" sounds a bit too weird :P [08:20:39] the french alternative sounds a bit better "déduplicable", but only for french I suppose :) [09:48:52] lunch [10:38:02] lunch [12:42:46] o/ [13:30:57] maybe "duplicated" instead of "deduplicatable"? Not sure if that conveys the concept well enough [13:31:09] \o [13:31:28] it's slightly different, deduplicated is after the deduplication has occured. Deduplicable is the state is being able to be deduplicated [13:34:08] o/ [14:47:02] maybe 'dedupable' ? [16:01:23] workout, back in ~40 [16:39:35] back [17:44:39] lunch, back in ~45 [18:30:46] back [20:30:45] meh, nothing is ever simple :P Now thinking about what exactly happens if we pass-through late events and let them skip deduplicate and merge. [20:30:47] t [20:38:31] so for example if we receive a delete then an undelete, but the delete is late, then they process out of order and the final state is the delete wins :S [23:11:32] intellij suggests the best names. inputEventInputEventOneInputStreamOperatorTestHarness