You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/08/24 08:37:41 UTC
propertyPK in AbstractSQLIndexing
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 in this case?
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: propertyPK in AbstractSQLIndexing
Posted by Stanislav Muhametsin <st...@zest.mail.kapsi.fi>.
On 25.8.2015 16:33, Niclas Hedhman wrote:
>
>
> On Tue, Aug 25, 2015 at 8:08 PM, Stanislav Muhametsin
> <stanislav.muhametsin@zest.mail.kapsi.fi
> <ma...@zest.mail.kapsi.fi>> 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 Apache Zest (Java
> Edition) ;-)
>
>
You could say that old habits die hard ;)
Re: propertyPK in AbstractSQLIndexing
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Aug 25, 2015 at 8:08 PM, Stanislav Muhametsin <
stanislav.muhametsin@zest.mail.kapsi.fi> 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 Apache Zest (Java
Edition) ;-)
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: propertyPK in AbstractSQLIndexing
Posted by Stanislav Muhametsin <st...@zest.mail.kapsi.fi>.
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.
Re: propertyPK in AbstractSQLIndexing
Posted by Paul Merlin <pa...@nosphere.org>.
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
Re: propertyPK in AbstractSQLIndexing
Posted by Stanislav Muhametsin <st...@zest.mail.kapsi.fi>.
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 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.
>> 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...
Re: propertyPK in AbstractSQLIndexing
Posted by Paul Merlin <pa...@nosphere.org>.
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 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?
> 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.
/Paul
Re: propertyPK in AbstractSQLIndexing
Posted by Stanislav Muhametsin <st...@zest.mail.kapsi.fi>.
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 the reason.
>
> (most ORM frameworks have pluggable key-generation strategies depending
> on the database used).
And yes, this would've been the proper solution.
I didn't know much about any stuff like that back in the days, so now
it's stuck with the application generating IDs, which of course makes it
incompatible in multiple applications -situation.
>
> Another thing is that the assigned values can be hard to grab on
> insertion - but not sure if that is really a requirement, or simply a
> coincidence in the implementation.
>
> /Kent
At least PostgreSQL has the "INSERT ... RETURNING" clause, but obviously
that is one more issue to solve through pluggable RDBMS-specific
mixins/callbacks.
>
>
> Den 24-08-2015 kl. 08:45 skrev 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-increment features in
>>> the DB.
>>> Why wasn't that done in this case?
>>>
>>>
>>> Cheers
>> Hmm, it's been years... Without looking at the code (since I have to
>> be at work in 15mins), I would make an educated guess that answer to
>> #1 is yes, and answer for #2 is no idea. I was quite a noobie back in
>> the days.
>
Re: propertyPK in AbstractSQLIndexing
Posted by Kent Sølvsten <ke...@gmail.com>.
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 thing is that the assigned values can be hard to grab on
insertion - but not sure if that is really a requirement, or simply a
coincidence in the implementation.
/Kent
Den 24-08-2015 kl. 08:45 skrev 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-increment features in
>> the DB.
>> Why wasn't that done in this case?
>>
>>
>> Cheers
>
> Hmm, it's been years... Without looking at the code (since I have to
> be at work in 15mins), I would make an educated guess that answer to
> #1 is yes, and answer for #2 is no idea. I was quite a noobie back in
> the days.
Re: propertyPK in AbstractSQLIndexing
Posted by Stanislav Muhametsin <st...@kapsi.fi>.
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-increment features in the DB.
> Why wasn't that done in this case?
>
>
> Cheers
Hmm, it's been years... Without looking at the code (since I have to be
at work in 15mins), I would make an educated guess that answer to #1 is
yes, and answer for #2 is no idea. I was quite a noobie back in the days.