Hi! On my system a transact returns a TxReport that includes in tx-data in version 0.3.2 [1 :attribute oldvalue tx false] and [1 :attribute newvalue tx true]. In 0.3.3 it does NOT report the oldvalue false but only the newvalue true. Is this intended or did I mess up my configuration?

nevermind. Just found it in the docs. It is normal behaviour.

The plot thickens: I have broken upsert on 3.3 for "ya29.A0AfH6SMBjh3CWIyNOUxs04GxbL5EPtj620nfm6WbUgCL83w7saG3hwk0cPQGhv4qkks4PX5cpMTmrDV-3czEEVuXf2deK-R-V-fQBlITRLT2gjdsBPauZnx6mfSvoNS69lD3XiATq83I_6wr_9cPY9NRCIG5f_A"

This is an oauth2/access token.

On an existing but freshly importet db of about 40000 datoms when I upsert a string to this value it is the last upsert on this [entity attribute] that works.

Meaning I can put this value into the db but it will never again be changed.

I do not get this with version 0.3.2.

With all my tests I used a freshly importet db in the same version (0.3.3 vs 0.3.2) the behaviour is only reproducible with 0.3.3.

Could there be something in the hashing algorithm of the google tokens that clashes with the hashing algorithms in datahike?

All tests done with a flat file db. I have NOT been able to reproduce with a minimal db of only a few datoms and schema.

I don't see a datalevin channel, but i wanted to ask: is the name a pun off breadmaking?

Hi @magra, this is unfortunate. What happens if you use integers (e.g. through hash) on the strings. In other words how is it specific to the oauth token type? Do you like to join our discord (link is in the channel description)? We try to build up better community communication and slack is somewhat limited. I have a feeling that this issue might need a bit of discussion. Please also open a Github issue if you can.