Google App Engine HRD запрос без предка

Question

У меня есть проект GAE, написанный на Java, и у меня есть некоторые мысли о HRD и проблема, которую я не знаю, как решить.

В основном у меня есть пользователи в моей системе. Пользователь состоит из идентификатора пользователя, имени пользователя, электронной почты и пароля. Каждый раз, когда я создаю нового пользователя, я хочу проверить, что еще нет пользователя с тем же идентификатором пользователя (никогда не должно быть), именем пользователя или электронной почтой.

Идентификатор пользователя является ключом, поэтому я думаю, что выполнение этого будет непротиворечивым. Однако, когда я делаю запрос (и использую фильтр), чтобы найти возможных пользователей с одинаковым именем пользователя или электронной почтой, я не могу быть уверен, что результаты будут согласованы. Поэтому, если кто-то создал пользователя с тем же именем пользователя или электронной почтой пару секунд назад, я, возможно, не найду его с моим запросом. Я понимаю, что предки используются для решения этой проблемы, но что, если у меня нет предка для использования в запросе? У пользователя нет родителя.

Я был бы рад услышать ваши мысли об этом, и то, что считается лучшей практикой в ​​таких ситуациях. Я использую Objectify для GAE, если это что-то меняет.

Answer 1

Я бы не рекомендовал использовать электронную почту или любой другой естественный ключ для вашей пользовательской сущности. Пользователи меняют свои адреса электронной почты, и вы не хотите в конечном итоге переписывать все ссылки на внешние ключи в своей базе данных всякий раз, когда кто-то меняет свой адрес электронной почты.

Вот короткое рекламное объявление о том, как я могу решить эту проблему:

https://groups.google.com/d/msg/google-appengine/NdUAY0crVjg/3fJX3Gn3cOYJ

Создать отдельную EmailLookup сущность которого @Id нормированная форма электронной почты (я только строчными все - технически неправильно, но сохраняет много боли, когда пользователи случайно используют Joe@example.com). Моя EmailLookup выглядит следующим образом:

@Entity(name="Email") 
public class EmailLookup { 
    /** Use this method to normalize email addresses for lookup */ 
    public static String normalize(String email) { 
     return email.toLowerCase(); 
    } 

    @Id String email; 
    @Index long personId; 

    public EmailLookup(String email, long personId) { 
     this.email = normalize(email); 
     this.personId = personId; 
    } 
} 

Существует также (не нормированные) электронной почты поле в моем User лица, которые я использую при отправке исходящих сообщений электронной почты (сохранить дело только в случае, если это важно для кого-то). Когда кто-то создает учетную запись с определенным электронным письмом, я загружаю/создаю EmailLookup и объекты пользователя по ключу в транзакции XG. Это гарантирует, что любой индивидуальный адрес электронной почты будет уникальным.

Та же стратегия применяется для любого другого уникального значения; facebook id, имя пользователя и т. д.

Answer 2

Путь вокруг HRD's eventual consistency, заключается в использовании get вместо query. Чтобы это сделать, вам нужно генерировать естественные идентификаторы, например. генерировать идентификаторы, которые состоят из данных, которые вы получаете в запросе: электронная почта и имя пользователя.

С get в HRD имеет сильную согласованность, вы сможете надежно проверить, существует ли пользователь.

Например читаемый естественный ID будет:

String naturalUserId = userEmail + "-" + userName; 

Примечание: на практике письма являются уникальными. Так что это хороший естественный идентификатор на своем собственном. Не нужно добавлять к нему добавленное имя пользователя.

Answer 3

Вы также можете включить транзакции между группами (см. https://developers.google.com/appengine/docs/java/datastore/overview#Cross_Group_Transactions), а затем в одной транзакции ищите пользователя и создайте новый, если это поможет.

Answer 4

Рекомендовать избегать индексированного поля и запроса, если у вас нет других применений. Вот что я сделал раньше (Python), используя key_name (поскольку идентификаторы объектов должны быть ints). Простота использования ключа или имени для других объектов, которые должны быть связаны с пользователем:

username = self.request.get('username') 
usernameLower = username.lower() 
rec = user.get_by_key_name(usernameLower) 
if rec is None: 
    U = user(
     key_name = usernameLower, 
     username = username, 
     etc...) 
    U.put() 
else: 
    self.response.out.write(yourMessageHere)