#3129 Fix to verify DBJson dirtiness using same field ordering on both sides (due to PostgreSQL reordering fields for JsonB types) #3405
Conversation
Fix to verify DBJson dirtiness using same field ordering on both sides (due to PostgreSQL reordering fields for JsonB types)
|
Hi @rbygrave, If you feel there is something missing to complete the PR or need additional information, do not hesitate to ask, we are available. 👍 Yours faithfully, |
|
Yeah sorry, been busy. At the back of my mind I'm wondering if there is another design option. That is, the design started from more the view that the json coming back out of the db would match the json going in, and I think that isn't holding up well. For example, the checksum for the content could be stored as a derived column and in that way we only care about the one direction in terms of json content and it's checksum. So I haven't quite had time to look at that design option yet, but that is the background thinking going on. |
|
No problem, it is to be sure that we could not have help more on our side. Great idea about storing object checksum as a derived data of the POJO. So that instead of comparing It would consume more disk space but the benefit is that it will speed up checksum comparison. |
Same as PR #3402 but starting / targeting
masterbranch.This pull request aim to fix a problem (#3129) where @DbJsonB fields are always considered dirty on load if the order of their properties do not match fields ordering from data stored in Postgres.
This is due to the fact that Postgres is re-ordering the fields if column type is a JsonB in order to optimize storage / index / etc...
To solve this problem, we parse/format the value coming from readSet method in order to be sure that comparison will be done using Java Jackson encoded JSON on both side.