Hi Prashant
If JsonB is PostgreSQL/JDBC specific, it makes sense to me as it's
implementation specific., so +1 from my side.
We should stay "abstract" in BasePersistence (and other interfaces).
If backward compatibility is good to have, it's best effort. Same for
zero downtime. We can do our best
Using JSONB in the PostgreSQL-specific implementation sounds reasonable to
me.
My impression from the in-progress PRs on this subject is that the effort
is focused
on PostgreSQL and reusing the SQL schema in different RDBMS systems is not
actually expected (or planned).
On the topic of compatibil
Thank you Dennis and Eric.
I agree whenever we introduce (2) in BasePersistence we should definitely
re:think if this is a query pattern
that can be supported by most of the DBs (Relational / NoSQL) before
accepting it for BasePersistence.
Presently this specific change is not gonna introduce any
I'm generally a +1 on using JSONB within Postgres.
However I am in agreement with Dennis that we should avoid his item (2)
above. If the application will need to load entities by some attributes A,
B, and C then we should create methods loadEntityByA(a: A),
loadEntityByB(b: B), and loadEntityByC(c
Re: "non-transactional", I guess it's more descriptive to refer to this new
implementation as "AtomicOperationJdbcPersistence" if it's confusing to say
"non-transactional"; the key is simply that we don't expose any
"runInTransaction" to the AtomicOperationMetaStoreManager layer.
Regarding Robert'
Thanks, Prashant, for working on this!
Using JSONB in the WIP JDBC implementation makes sense. For the EclipseLink
implementation, I'd recommend keeping the current schema as-is (without
JSONB) so existing users don’t need to go through a migration.
If users do want to migrate, I’d suggest moving
Hi Robert,
Thank you for your response!
To clarify my point about "non-transactional" operations, I meant that most
operations don't require full transactions, with the exception of methods
such as writeEntities. For this specific case, Dennis created a new
implementation of Polaris MetaStore Man
Hey Prashant,
thanks for working on this!
I'm a bit confused about "non transactional Postgres" - how's PG not
transactional? If so (like one DML per tx), how is consistency
guaranteed, because IIRC the requirements that some people voiced is to
keep the same schema as the current Eclipselink
