On 25.8.2015 15:02, Paul Merlin wrote:
Reading some code ...
SQLEntityState is the sole reason SQLEntityStore is not a
JSONMapEntityStore.
SQLEntityState in fact is a DefaultEntityState decorated to add PK and
OptimisticLock data.
We should refactor this for 3.0: ZEST-116
A proposition: despite of the interfaces/callbacks that will be used to
extract "next PK" from database, the implementation should get X amount
of primary keys (say, 10 by default) from database. Then return the
first one, and cache the remaining ones, so that SQL connection wouldn't
be required *every* time the Qi4j runtime will request the primary key.
The amount of primary keys to get per chunk should be configurable via
Qi4j configuration mechanism.
Indexing-SQL uses either type-derived-info for PKs or database
generated return values. So it should not suffer from the
multi-instances-app issue. Cool.
Thanks a lot for finding out, Paul! :)
I don't have access to Qi4j codebase right now on my work computer, so
couldn't check.
