polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Muhametsin <stanislav.muhamet...@zest.mail.kapsi.fi>
Subject Re: propertyPK in AbstractSQLIndexing
Date Tue, 25 Aug 2015 12:08:40 GMT
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.

View raw message