Re: propertyPK in AbstractSQLIndexing

2015-08-25 Thread Niclas Hedhman
On Tue, Aug 25, 2015 at 8:08 PM, Stanislav Muhametsin < [email protected]> wrote: > > 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. > Stan, perhaps you missed it... Qi4j is Dead, Long Live Ap

Re: propertyPK in AbstractSQLIndexing

2015-08-25 Thread Stanislav Muhametsin
On 25.8.2015 16:33, Niclas Hedhman wrote: On Tue, Aug 25, 2015 at 8:08 PM, Stanislav Muhametsin > wrote: 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.

Re: propertyPK in AbstractSQLIndexing

2015-08-25 Thread Stanislav Muhametsin
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: despi

Re: propertyPK in AbstractSQLIndexing

2015-08-25 Thread Paul Merlin
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

Re: propertyPK in AbstractSQLIndexing

2015-08-25 Thread Stanislav Muhametsin
On 25.8.2015 13:48, Paul Merlin wrote: Gang, Niclas Hedhman a écrit : Paul (or Stan?) 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

Re: propertyPK in AbstractSQLIndexing

2015-08-25 Thread Paul Merlin
Gang, Niclas Hedhman a écrit : > Paul (or Stan?) > > 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 discusse

Re: propertyPK in AbstractSQLIndexing

2015-08-24 Thread Stanislav Muhametsin
On 24.8.2015 10:02, Kent Sølvsten wrote: Just guessing. Could it have something to do with an attempt to be compatible with multiple databases? As far as i remember, Oracle does not support autoincrement (but has sequences instead). Hmm, yeah, the compatibility requirement/feature probably was

Re: propertyPK in AbstractSQLIndexing

2015-08-24 Thread Kent Sølvsten
Just guessing. Could it have something to do with an attempt to be compatible with multiple databases? As far as i remember, Oracle does not support autoincrement (but has sequences instead). (most ORM frameworks have pluggable key-generation strategies depending on the database used). Another t

Re: propertyPK in AbstractSQLIndexing

2015-08-23 Thread Stanislav Muhametsin
On 24.8.2015 9:37, Niclas Hedhman wrote: Paul (or Stan?) 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? 2. Normally, one would depend on the auto-increm

propertyPK in AbstractSQLIndexing

2015-08-23 Thread Niclas Hedhman
Paul (or Stan?) 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? 2. Normally, one would depend on the auto-increment features in the DB. Why wasn't that done