Maybe not the best time to promote a library using Java serialization.
Java Serialization is probably the number 1 source of serious Java vulnerabilities since applets, and it isn’t even particularly fast compared to other serialization libraries that target JSON or something else
It works with xstream, and I’m sure it could support Jackson, or whatever. The hard part is picking which layer to serialize and resisting the urge to re-implement Dynamo.
Heh, good spot. Funny enough, it was upgraded to log4j2 somewhat recently in https://github.com/prevayler/prevayler/issues/24 to remediate CVE-2019-17571, which it probably wasn't even vulnerable to. I wonder how many other people did the same thing. I wish security advisories did a better job explaining the circumstances of when something is exploitable.
I recently implemented something like this in Go, basically just a tiny bit of glue between encoding/json and pgx (for JSONB columns). With generics, it's trivial to wrap any Go struct into an ACID record.
Quite nice for rapid development without getting buried by ORMs or NoSQL, and it becomes easy to migrate the "soft" JSONB columns to "hard" DDL schemas as performance requires it.
I assume so but not sure. I'm also keeping the ACID wrapper as simple as possible and not trying to implement e.g. joins, with the idea that highly relational data should be "hardened" anyways into proper (de)normalized DDL.
It is really easy to implement indexes and multi-column unique constraints generically over JSONB (in the Go wrapper), which is nice.
I remember the crazy hype they had around this when it was introduced over a decade ago. All the bizarre claims comparing it to being “a million times faster than RDBMS databases” when in fact it was just in-memory objects that were periodically written out with stream.writeObject().
13 comments
[ 47.4 ms ] story [ 809 ms ] threadhttps://github.com/klauswuestefeld/prevayler-clj
If one does need Java object persistence perhaps this seems better maintained [1]
1. https://microstream.one/
Quite nice for rapid development without getting buried by ORMs or NoSQL, and it becomes easy to migrate the "soft" JSONB columns to "hard" DDL schemas as performance requires it.
Are there cases wherein GIN indexes on the JSONB columns aren't sufficient for performance requirements?
It is really easy to implement indexes and multi-column unique constraints generically over JSONB (in the Go wrapper), which is nice.