Re: Affinity Key column to be always part of the Primary Key

Based this latest description, simply not specifying an affinity key here would be sufficient. But presumably you were specifying the affinity key to cause co-location. The reason a lookup on the K of the KV pair is fast is because it can hash to a node. If the affinity key was not

Re: Affinity Key column to be always part of the Primary Key

My whole and sole requirement is to make lookup work fast, this can only be achieved with lookup based on primary key, cluster knows which node is holding this record based on the key, no other look-up can give best results close to primary key lookup. We have done some tests on lookup based on

Re: Affinity Key column to be always part of the Primary Key

What is your goal? If you have a unique key that does not contain the affinity key, and the primary key contains both fields, you can create an index on that unique key, so that you could have fast node local lookups using SqlQuery().If you want to find an object only by that original unique

Re: Affinity Key column to be always part of the Primary Key

Because without AFFINITY KEY option we do not know order of fields within composite PK which is very important for index creation. вт, 20 марта 2018 г. в 19:58, Dmitriy Setrakyan : > On Tue, Mar 20, 2018 at 2:09 PM, Vladimir Ozerov > wrote: > >>

Re: Affinity Key column to be always part of the Primary Key

On Tue, Mar 20, 2018 at 2:09 PM, Vladimir Ozerov wrote: > Internally Ignite is key-value storage. It use key to derive partition it > belongs to. By default the whole key is used. Alternatively you can use > @AffinityKey annotation in cache API or "affinityKey" option in

Re: Affinity Key column to be always part of the Primary Key

Internally Ignite is key-value storage. It use key to derive partition it belongs to. By default the whole key is used. Alternatively you can use @AffinityKey annotation in cache API or "affinityKey" option in CREATE TABLE to specify *part of the key* to be used for affinity calculation. Affinity

Re: Affinity Key column to be always part of the Primary Key

Yes, the affinity key must be part of the primary key. Welcome to my world On Fri, Mar 16, 2018 at 3:23 AM, Naveen wrote: > Hi Mike > > I have created a table called CITY > > : jdbc:ignite:thin://127.0.0.1> CREATE TABLE City ( city_id LONG PRIMARY > KEY, name

Re: Affinity Key column to be always part of the Primary Key

Hi Mike I have created a table called CITY : jdbc:ignite:thin://127.0.0.1> CREATE TABLE City ( city_id LONG PRIMARY KEY, name VARCHAR) WITH "template=replicated"; No rows affected (0.224 seconds) Creating a table called Person with affinity key as city_id 0: jdbc:ignite:thin://127.0.0.1>

Re: Affinity Key column to be always part of the Primary Key

Hi Naveen >If I do not have the affinity key column as part of the primary key, it does >not allow me to create the table itself. Could you please explain how it doesn't allow you create the table? is there any exceptions/errors messages? Thanks, Mike. -- Sent from:

Re: Affinity Key column to be always part of the Primary Key

Do we have any update on this clarification regarding the affinity Thanks Naveen -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Affinity Key column to be always part of the Primary Key

Hi Stan If I do not have the affinity key column as part of the primary key, it does not allow me to create the table itself. If I want to execute a join query on both the tables, I had to use affinity key to collocate the data select p.party_id, a.party_id, first_name, A.SERVICE_ID_LIST from

Re: Affinity Key column to be always part of the Primary Key

Generally, you should have an index for each combination of fields you use in a query. Primary key gives you an implicit index, but you need to create the rest yourself. In your case, I'd suggest to have AccountID as a primary key (without PartyID) and also create a compound index for the pair

Affinity Key column to be always part of the Primary Key

. And affinity key column should be always part of the primary key. So Account table will have a composite key consisting of AccountID, PartyID. My question is, while querying the data from Account table, how does the query work 1. If I only pass AccountID 2. If I pass both AccountID and PartyID if I