-1

Is there a way to use collocation (affinity key) and keep using key\value API without affinity key (just the id itself)?

I'd like to take advantage of collocation using SQL queries but in the same time keep using the key/value API. I mostly use it to specifically sync cache entities (using readthrough), which I cannot do with SQL.

I tried use AffinityKey but I noticed that key/value API search for a complete match of both key and affinity key. For example, I need the key/value API to take advantage of the readthrough capability when I want to load new entity in the DB to the cache. I use get(id) and because its not in the cache its been loaded from DB - the problem is that using AffinityKey I must also provide the initial affinity key value (in addition to the id) to have a match...

Is there a way to map object by affinity but still working with original integer key? Or maybe use AffinityKey but somehow ignore the affinity key value and use the id only. BTW I've noticed that (unfortunately) key/value API doesn't use AffinityKey.equals, seems like there is some wrapper KeyCacheObject, otherwise the AffinityKey.equals would have found a match.

greybeard
  • 2,249
  • 8
  • 30
  • 66
ofer.ignite
  • 1
  • 1

1 Answers1

0

No, doesn't work like that. Affinity Key must be a part of the Primary Key.

If you have your original primary key i, and you want to add an affinity key ak, you'll have a complex primary key (i, ak).

If you didn't need the read-through, then to lookup an object by the key i you could use SQL: new SqlQuery("where i = ?").setArgs(iToLookup). I'm pretty sure you can also use the Spring Data integration to and declare a method like Optional<Integer> findByI(int i) which would hide the SQL query completely.

Unfortunately, SQL won't give you the read-through support. In fact with Ignite's architecture, you're supposed to know thee affinity key of the entry you'll be reading with read-through. I thing there is no direct workaround here.

I suggest to look at two things:

  1. Look at your affinity key; if it can be computed from the primary key, compute it automatically in a custom wrapper around IgniteCache. If it can't be computed from the primary key, the chances are that your data model doesn't really fit the Ignite's collocation model.

  2. Consider doing this without read-through; you can build a smart data access layer that looks up Ignite first, and then fetches the entry from the DB into Ignite if Ignite currently doesn't have it.

Stanislav Lukyanov
  • 2,147
  • 10
  • 20
  • thx for your answer. for the example, i have "id" as primary key for person and companyId (FK "ic" from Company), I'd like both relevant person with its company's data on the same node. I cannot see how i can use only person id (computed or not) to achieve that. so to ensure that is need key(personId, companyId), which interfere with that fact i want to use read through as it save logic understanding whether person (and all other entities) are in cache - simple get, instead of 2 sql queries (one to see if exists and the other to retrieve it) – ofer.ignite Jun 12 '22 at 05:08
  • In addition, and this is the major problem, due to the fact we dont have companyId when querying person, we must do all queries/CRUD using sql. using affinity key we loose the ability to have direct access to cache objects using their keys (get, delete and etc) – ofer.ignite Jun 12 '22 at 05:30