Android Firestore ограничения для пользовательских моделей объектов - PullRequest
0 голосов
/ 15 января 2019

Я перевожу свое приложение для использования Firebase Firestore, и одна из моих моделей очень сложна (содержит списки других пользовательских объектов). Глядя на документацию, о том, как зафиксировать объект модели как документ, похоже, что вы просто создаете объект модели с помощью открытого конструктора, а также методов получения и установки.

Например, из руководства по добавлению данных:

public class City {
    private String name;
    private String state;
    private String country;
    private boolean capital;
    private long population;
    private List<String> regions;

    public City() {}

    public City(String name, String state, String country, boolean capital, long population, List<String> regions) {

    // getters/setters
}

Firestore автоматически переводит это в и из и документирует без каких-либо дополнительных шагов. Вы передаете экземпляр в DocumentReference.set(city) вызов и извлекаете его из вызова в DocumentSnapshot.toObject(City.class)

Как именно он сериализует это в документ? Через отражение? Здесь не обсуждаются какие-либо ограничения. По сути, мне интересно, будет ли это работать на более сложных моделях и насколько они сложны. Будет ли это работать для класса с ArrayList пользовательских объектов?

1 Ответ

0 голосов
/ 15 января 2019

Firestore автоматически переводит это в и из и документирует без каких-либо дополнительных шагов. Как именно это сериализовать это в документ? Через отражение?

Ты угадаешь правильно, через отражение. Как также отметил @Doug Stevenson в своем комментарии, для систем, таких как Firebase, очень распространено преобразование данных JSON в POJO (Plain Old Java Object). Также обратите внимание, что сеттеры не требуются. Если для свойства JSON нет установщика, клиент Firebase установит значение непосредственно в поле. Конструктор с аргументами также не требуется. В то время как оба являются идиоматическими, есть хорошие случаи иметь классы без них. Пожалуйста, взгляните также на некоторые сведения о существовании конструктора без аргументов .

Здесь не обсуждаются какие-либо ограничения.

Да, это так. Официальная документация объясняет, что документы имеют ограничения. Таким образом, существуют некоторые ограничения в отношении объема данных, которые вы можете поместить в документ. Согласно официальной документации относительно использования и ограничений :

Максимальный размер документа: 1 МБ (1 048 576 байт)

Как видите, вы ограничены 1 МБ данных в одном документе. Когда мы говорим о сохранении текста, вы можете хранить его в значительной степени, но по мере увеличения массива (с пользовательскими объектами) будьте осторожны с этим ограничением.

Обратите также внимание, что если вы храните большой объем данных в массивах, и эти массивы должны обновляться многими пользователями, есть еще одно ограничение, о котором вам нужно позаботиться. Таким образом, вы ограничены 1 записью в секунду на каждый документ. Поэтому, если у вас есть ситуация, когда многие пользователи пытаются одновременно записать / обновить данные в одни и те же документы, вы можете увидеть, что некоторые из этих операций записи завершаются неудачно. Так что будьте осторожны с этим ограничением.

Будет ли это работать для класса с ArrayList пользовательских объектов?

Он будет работать с любыми типами классов, если поддерживает тип данных объекты.

По сути, мне интересно, будет ли это работать на более сложных моделях и насколько они сложны.

Он будет работать с любым типом сложной модели, если вы используете правильные типы данных для ваших объектов и ваши документы находятся в пределах этого ограничения в 1 MIB.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...