Зажигать словосочетание между кешами с разными ключами сходства - PullRequest
Новая
       11

Зажигать словосочетание между кешами с разными ключами сходства

0 голосов
/ 29 ноября 2018

Допустим, у меня есть две таблицы в отдельных кешах Ignite, A и B с соответствующими ключами: 

case class AKey(
    @(QuerySqlField@field) id: Long,
    @(AffinityKeyMapped@field)
    @(QuerySqlField@field) parentId: Long
)

case class BKey(
    @(AffinityKeyMapped@field)
    @(QuerySqlField@field) aId: Long
)

Где A.parentId - это собственная ссылка на другую запись в таблице A и B.aId является ссылкой на A.id.

Если я хочу, чтобы все A записи с одним и тем же parentId были сопоставлены, но я также хочу, чтобы все B записи были сопоставлены с parentId ссылочной записи A, какя бы установил это родство без включения поля parentId в B?Или это невозможно?

Из документации Ignite мне не ясно, как Ignite устанавливает связь между таблицами.

1 Ответ

0 голосов
/ 30 ноября 2018

Как Ignite управляет расположением аффинности

На самом деле Ignite не устанавливает никаких «отношений аффинности».Все, что он делает - это отображение ключей кеша на ключи сродства.Все записи во всех кэшах с одним и тем же ключом гарантированно размещаются совместно.

Например, берут кэши со следующими ключами 

class KeyA { int a1; int a2; @AffinityKeyMapped int affKey; }
class KeyB { int b1; int b2; @AffinityKeyMapped int affKey; }

Здесь мы говорим, что KeyA и KeyBразмещается через affKey - когда значения affKey совпадают, записи будут размещены.Но на самом деле Ignite не знает о связи между KeyA и KeyB, он обрабатывает таблицы отдельно.Только гарантия того, что сопоставление ключа схожести с узлом является последовательным, делает эту работу.Другими словами, связь между этими кешами существует только в наших головах, и мы несем ответственность за обеспечение правильного расположения.

Решение

Наконец, по вашему делу.Это может быть удивительно, но parentId не очень хороший кандидат на ключ сродства.Скажем, у нас есть три значения в A 

{ id: 1, parentId: 0 }
{ id: 2, parentId: 1 }
{ id: 3, parentId: 2 }

Здесь можно ожидать, что все значения будут размещены в одном месте, поскольку все они ссылаются друг на друга в одной и той же «цепочке».Но это отношения, о которых Игнит не знает.Все, что он знает, это то, что есть три разных значения parentId - следовательно, три разных ключа аффинности и отсутствие словосочетания.

Для правильной обработки это должно обеспечить некоторое groupdId, которое гарантированно будет одинаковым для всехвсе значения.Естественным соответствием в вашем случае будет идентификатор корневого элемента в «дереве».Тогда groupdId будет @AffinityKeyMapped. 

{ id: 1, parentId: 0, groupId: 1 }
{ id: 2, parentId: 1, groupId: 1 }
{ id: 3, parentId: 2, groupId: 1 }

К сожалению, второй кэш должен ссылаться на точно такое же значение ключа привязки, и нет способа сделать это без добавления этого какполе. 

{ aId: 2, aGroupId: 1 }

Кроме того, хотя это не имеет прямого отношения к вопросу, убедитесь, что @AffinityKeyMapped является частью кеша ключ , а не частью значения- иначе он будет проигнорирован.

...