Итак, у меня есть собственный подкласс OrmLiteSqliteOpenHelper. Я хочу использовать интерфейс ObjectCache, чтобы убедиться, что у меня есть сопоставление идентификаторов из строк БД в объекты в памяти, поэтому я переопределяю getDao(...) как:
@Override
public <D extends Dao<T, ?>, T> D getDao(Class<T> arg0) throws SQLException {
D dao = super.getDao(arg0);
if (dao.getObjectCache() == null && !UNCACHED_CLASSES.contains(arg0))
dao.setObjectCache(InsightOpenHelperManager.sharedCache());
return dao;
}
Насколько я понимаю, super.getDao(Class<T> clazz) в основном выполняет вызов DaoManager.createDao(this.getConnectionSource(),clazz) за кулисами, который должен найти кэшированный DAO, если таковой существует. Однако ...
final DatabaseHelper helpy = CustomOpenHelperManager.getHelper(StoreDatabaseHelper.class);
final CoreDao<Store, Integer> storeDao = helpy.getDao(Store.class);
DaoManager.registerDao(helpy.getConnectionSource(), storeDao);
final Dao<Store,Integer> testDao = DaoManager.createDao(helpy.getConnectionSource(), Store.class);
Я ожидаю, что (даже без вызова registerDao(...)) storeDao и testDao должны быть ссылками на один и тот же объект. Однако я вижу это в отладчике Eclipse:
Кроме того, кэш объектов testDao равен нулю.
Я что-то здесь не так делаю? Это ошибка?
У меня есть специальный менеджер помощников, но только потому, что мне нужно было управлять несколькими базами данных. Это просто хэш-карта Class<? extends DatabaseHelper> ключей для экземпляров.
Причина, по которой мне нужен мой кешированный DAO, заключается в том, что у меня есть несколько внешних коллекций, которые активно загружаются внутренними сгенерированными DAO, которые не используют мой глобальный кэш и, таким образом, воссоздаются независимо для каждой коллекции.
Когда я писал это, я думал, что могу просто переопределить мой helpy.getDao(...) вызов до DaoManager.createDao(...), но это приводит к тому же самому: я все еще получаю другой DAO при втором вызове createDao(...) , Мне кажется, что это полностью против документов для DaoManager.
Во-первых, я думал, что это выглядит как registerDao(...) может быть виновником:
public static synchronized void registerDao(ConnectionSource connectionSource, Dao<?, ?> dao) {
if (connectionSource == null) {
throw new IllegalArgumentException("connectionSource argument cannot be null");
}
if (dao instanceof BaseDaoImpl) {
DatabaseTableConfig<?> tableConfig = ((BaseDaoImpl<?, ?>) dao).getTableConfig();
if (tableConfig != null) {
tableMap.put(new TableConfigConnectionSource(connectionSource, tableConfig), dao);
return;
}
}
classMap.put(new ClassConnectionSource(connectionSource, dao.getDataClass()), dao);
}
То, что return в строке 230 источника для DaoManager препятствует обновлению classMap (так как я использую предварительно сгенерированные файлы конфигурации?). Когда мой код попадает во второй вызов create, он сначала смотрит на classMap и каким-то образом (вопреки моему лучшему пониманию) находит другую копию DAO, живущую там. Что очень странно, потому что, шагая через первое создание, я наблюдал, как инициализируется classMap.
Но откуда взялся бы второй DAO?
С нетерпением жду понимания Грея! : -)