Here is how I tested this, and I have questions about part of the behaviour as I'm not sure if my expectations are misaligned or if the behaviour is legitimately questionable. My expectations are based on what I understand "History Mode" to be, not on an understanding of how associative actually works:
During the first 10 seconds, I run in the database:
postgres=# insert into test(id, x) values (1, 'created'); update test set x='updated' where id=1; delete from test; insert into test(id, x) values (1, 'created'); update test set x='updated' where id=1;
After 10 seconds, I get these reduced documents from the capture preview:
This means the events from my first run of insert, update, delete and again insert and update have all been reduced to one document. This does not match my expectation that each event will be emitted separately.
Then I run this command on the database, with the same flowctl preview running:
postgres=# delete from test; insert into test(id, x) values (1, 'created'); update test set x='updated' where id=1; delete from test; insert into test(id, x) values (1, 'created'); update test set x='updated' where id=1;
This does match my expectation that each event has its own document now and the sequence is okay. This did not happen for the first run, but on subsequent updates / deletes to the documents, events seem to be emitted separately.
Now I run the same process, this time with associative: true, that is:
postgres=# insert into test(id, x) values (1, 'created'); update test set x='updated' where id=1; delete from test; insert into test(id, x) values (1, 'created'); update test set x='updated' where id=1;
So far, this is the same as associative: false for the first set of events. Then I run:
postgres=# delete from test; insert into test(id, x) values (1, 'created'); update test set x='updated' where id=1; delete from test; insert into test(id, x) values (1, 'created'); update test set x='updated' where id=1;
Here this is also a bit strange, because the deletion event seems to be emitted separately, but the create and update events are not emitted separately and are reduced. This seems to be the difference between associative: true and false. But it is not as I expect it to be either. In case of non-history-mode, I would expect to have only one document emitted which would be the final updated document. The deletion does not need to be there. Note that I don't have a delete reduction annotation here.
Description:
Here is how I tested this, and I have questions about part of the behaviour as I'm not sure if my expectations are misaligned or if the behaviour is legitimately questionable. My expectations are based on what I understand "History Mode" to be, not on an understanding of how associative actually works:
Here is my schema:
I start with a postgres database with a table
test
with no records. I then run:During the first 10 seconds, I run in the database:
After 10 seconds, I get these reduced documents from the capture preview:
This means the events from my first run of
insert
,update
,delete
and againinsert
andupdate
have all been reduced to one document. This does not match my expectation that each event will be emitted separately.Then I run this command on the database, with the same
flowctl preview
running:This time, after 10 seconds I get:
This does match my expectation that each event has its own document now and the sequence is okay. This did not happen for the first run, but on subsequent updates / deletes to the documents, events seem to be emitted separately.
Now I run the same process, this time with
associative: true
, that is:Then:
And:
I get:
So far, this is the same as
associative: false
for the first set of events. Then I run:I get:
Here this is also a bit strange, because the deletion event seems to be emitted separately, but the create and update events are not emitted separately and are reduced. This seems to be the difference between
associative: true
andfalse
. But it is not as I expect it to be either. In case of non-history-mode, I would expect to have only one document emitted which would be the final updated document. The deletion does not need to be there. Note that I don't have a delete reduction annotation here.This change isβ![Reviewable](https://reviewable.io/review_button.svg)