polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: propertyPK in AbstractSQLIndexing
Date Tue, 25 Aug 2015 12:02:33 GMT
Reading some code ...

Stanislav Muhametsin a écrit :
>>> In the above class there is a propertyPK that is passed around for each
>>> insertion and +1 and so on.
>>>    1. Does that mean that SQL Indexing will not work for
>>> multi-instances of Zest app?
>> That's correct :(
>> I remember this has been discussed in the past, but can't find a link.
>> IIRC that is also the sole reason why SQLEntityState exists and the
>> SQLEntityStore is not a JSONMapEntityStore. Stan?
> There was a reason, yes, since I initially tried to make it
> JSONMapEntityStore.
> I don't remember actual reason anymore though, I guess SQLEntityStore
> needed some special behaviour that JSONMapEntityStore did not
> provide/expose.
SQLEntityState is the sole reason SQLEntityStore is not a
SQLEntityState in fact is a DefaultEntityState decorated to add PK and
OptimisticLock data.
We should refactor this for 3.0: ZEST-116

>>>    2. Normally, one would depend on the auto-increment features in
>>> the DB.
>>> Why wasn't that done in this case?
>> Probably for compatibility reasons as Kent & Stan pointed out.
>> But it should be doable with strategies per 'type of sql db'.
>> Some support auto-increments, some requires sequences etc...
>> I wonder if the Indexing-SQL extension suffers from the same issue.
> Don't think it should, since the primary keys are generated from type
> information, IIRC.
> I might be wrong though...

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message