Отношения «многие ко многим» в Objectify со строгой согласованностью

Будучи новичком в Google Cloud Datastore, я хотел бы убедиться, что я на правильном пути.

Что мне нужно:

  • отношение многие ко многим
  • само отношение должно содержать данные, описывающие отношение
  • strong consistency is required both ways:
    • from user entity to all the data entities that this user has permissions to
    • от объекта данных всем пользователям, у которых есть на это разрешение

Вот что я придумал:

@Entity
public class User {
    @Id String userId;
}

@Entity
public class PermissionIndex {
    @Id long id;
    @Parent Key<User> user;
    List<Ref<Permission>> permissions;
}

@Entity
public class Permission {
    @Id long id;
    boolean writePermission;
    boolean managePermission;
    @Load Ref<Data> data; //So that Data entities can be retrieved with strong
                          //consistency after looking up Permission entities
                          //for a specific User entity
    @Load Ref<User> user; //So that User entities can be retrieved with strong
                          //consistency after looking up Permission entities
                          //for a specific Data entity
}

@Entity 
public class DataIndex {
    @Id long id;
    @Parent Key<Data> data;
    List<Ref<Permission>> permissions;
}

@Enti.
public class Data {
    @Id String dataId;
    @Id String actualData;
}

Если я правильно понимаю эту реализацию, единственный способ отфильтровать объекты данных конкретного пользователя — это получить все объекты разрешений и отфильтровать объекты данных в памяти, я прав?

Есть ли лучший способ реализовать его, все еще выполняя требования?

ОБНОВЛЕНИЕ:

Насколько я понимаю, эта реализация позволит мне реализовать логику, которая будет извлекать данные, обеспечивая строгую согласованность (имея идентификатор пользователя - запрос предка для извлечения всех объектов разрешений, а затем использование get_by_key для извлечения объектов данных).

Мне интересно, следует ли мне подходить к этому по-другому, поскольку у меня нет большого опыта работы с хранилищем данных/объективацией.


person gswierczynski    schedule 18.09.2014    source источник
comment
Интересно, почему этот вопрос был отклонен. Пожалуйста, оставьте комментарий, объясняющий, почему вы считаете, что на него не стоит отвечать, или как я могу его улучшить.   -  person gswierczynski    schedule 19.09.2014


Ответы (2)


Вопросу присуще важное концептуальное недоразумение: отношения не являются строго или в конечном счете последовательными. Запросы есть.

Если вы выполняете операцию получения по ключу, результат будет строго согласованным. Если вы выполняете запрос фильтра без предка, результат в конечном итоге будет согласованным. Перефразируя это:

Если вы перемещаетесь по графу объектов с помощью операций получения по ключу, вы увидите строгую согласованность. Если вы перемещаетесь по графу объектов, используя фильтры запросов, не относящиеся к предкам, вы увидите конечную согласованность.

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

person stickfigure    schedule 18.09.2014
comment
вы правы - описание, которое я предоставил, может ввести в заблуждение. Я имел в виду следующее: я думаю, что эти реализации позволяют мне использовать средства поиска, которые обеспечат строгую согласованность - получение списка объектов разрешений с использованием запроса предка, а затем использование get_by_key для получения объекта данных. Сказав это, мне интересно, есть ли лучший дизайн, который позволил бы использовать способы поиска данных, обеспечивающие строгую согласованность. - person gswierczynski; 19.09.2014
comment
Трудно дать конкретный совет, не зная больше о проблемной области, но обычно объекты разрешений естественным образом являются частью группы сущностей пользователя; разрешения обычно не меняются очень часто или, по крайней мере, не меняются чаще, чем User. Еще один совет, который я могу дать, заключается в том, что сильную последовательность часто переоценивают. Эвентуал обычно довольно быстрый. - person stickfigure; 19.09.2014
comment
Я был бы рад реализовать логику, которая работала бы безукоризненно с эвентуальной согласованностью, но мне нужно реализовать синхронизацию между сервером и удаленными устройствами (которые могут работать в автономном режиме), а эвентуальная согласованность может привести к несоответствиям. Идея здесь заключается в том, что пользователь может регистрировать данные, а затем делиться этими данными с другими пользователями (с выбираемыми разрешениями для этих конкретных данных — что-то вроде обмена фотографиями на социальных сайтах, но с разными разрешениями для каждого пользователя). Не поймите меня неправильно - я очень ценю ваш вклад. Может оказаться, что я на правильном пути. - person gswierczynski; 19.09.2014

Ваша логика кажется здравой... но для реляционной базы данных.

Такая логика не работает в HRD, который является хранилищем данных. Очевидно, есть способы обойти это, и вы поняли их так, как вы описали.

Для согласованности ваш единственный шанс — использовать запросы предков. Хранилище данных в конечном итоге является согласованным, только с помощью «get_by_key» или запроса предка вы можете «форсировать» согласованность.

Если вы хотите что-то более близкое к SQL, возможно, стоит рассмотреть облачный GQL?

person Patrice    schedule 18.09.2014
comment
Реализация вопроса заключается в предоставлении способа извлечения данных при обеспечении строгой согласованности (ограничение запросами get_by_key и предков - получение списка разрешений с использованием запроса предка, а затем использование get_by_key для получения данных). У меня большой опыт работы с SQL, но я хочу добиться описанного результата с Google Cloud Datastore. IMO, это решение в настоящее время кажется разумным для реляционной базы данных. - person gswierczynski; 19.09.2014