GreenDao и наследование объектов

Question

Моя задача - сделать кэш на ОС Android для моего приложения (это своего рода мессенджер). Я хотел бы хранить сообщения в базе данных, но встретил проблему хранения различных типов сообщений (в настоящее время 5 типов сообщений для каждого типа есть это собственные поля и все они расширяют базовый класс)

GreenDao documentation говорит:

Note: currently it’s impossible to have another entity as a super class (there are no polymorphic queries either)

Я планирую иметь юридическое лицо, которое почти 1 к 1 к базовому классу, за исключением одного столбца - необработанных двоичных или JSon данных, в которой каждый класс ребенок может писать все, что ему нужно.

Мои вопросы:

1. GreenDao является хорошим решением в таком случае? Есть ли какие-либо решения, которые позволяют не беспокоиться о наследовании - и насколько они стоили с точки зрения эффективности.
2. Как «сериализовать» данные в таком поле (какой метод я должен переопределить или где я должен поместить свой код, который будет делать все необходимые вещи
3. Как дать правильному конструктору GreenDao «десериализацию» Json или двоичный код для исправления класса экземпляр
4. Должен ли я использовать отражение - или просто переключитесь/случай для нахождения правильного конструктора (только 5 типов конструкторов возможно) - это отражение того, сколько будет отражением «стоимость» в таком случае

Answer 1

Если вы на самом деле? нужно наследование greendao - это не то, что я получаю, потому что он его не поддерживает. Но я думаю, что вы можете пойти без наследования:

Вы можете создать объект с столбцом дискриминатора (messagetype) и двоичным или текстовым столбцом (данными). Затем вы можете использовать абстрактный завод для создания желаемых объектов из данных в зависимости от типа сообщения.

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

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