Yeah, I was trying to do something that would be able to use on multiple tables that would allow me using the SS OrmLite ModelDefinition to build the SQL update so that any changes wouldn’t affect the SQL or have to code for many Custom SQL for each data model that do the same thing.
Currently almost every table has at least one json/jsonb field, so creating custom sql for each and keeping it up to date when data models change (it’s a new project) is a little tedious.
With json fields apart of every db and them being using more frequently with NoSQL type storage and SPA interacting with them, situations where data overwrites (if sql column update) can happen on json fields is increasing.
If I did have a way to get jsonb_set using OrmLite and posted it, is that something you would think about putting in OrmLite for everyone? Most db’s have some sort of json_modify function.
The only thing is that you’d probably want it to work for all situations (deep/nested objects) and not just first level keys. Though I’m not sure if I have the time to go that far. You probably wouldn’t include it if it didn’t work in those nested scenarios?
It would need to depend on what the Typed API looked like, whether it’s a good fit for OrmLite and intuitive to use.
It’s ok if it only worked for partial situations as long as support for more complete implementation doesn’t break backwards compatibility of existing APIs, if it might it should be marked with [Obsolete] until we’re confident on an API that’s future proofed.