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 JSONMapEntityStore. 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. Cool. /Paul
