2012-02-14 10 views
1

私はOrmLiteSqliteOpenHelperのカスタムサブクラスを持っています。私の理解では、super.getDao(Class<T> clazz)は基本的に背後DaoManager.createDao(this.getConnectionSource(),clazz)への呼び出しを行っているということですDaoManagerのORMLite OpenHelper DAOキャッシュ?

@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; 
} 

:私は、私は、メモリ内のオブジェクトにDBの行からアイデンティティマッピングを持っていることを確認するためにObjectCacheインタフェースを使用したいので、私はとしてgetDao(...)を上書きシーンが存在する場合、キャッシュされた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); 

は、私が(でもW/O registerDao(...)コール)storeDaotestDaoが同じオブジェクトへの参照であることを期待します。しかし私は、Eclipseのデバッガでこれを参照してください。

Different object IDs

また、testDaoのオブジェクトキャッシュがnullです。

ここで何か問題がありますか?これはバグですか?

私はカスタムヘルパーマネージャを持っていますが、複数のデータベースを管理する必要があったためです。インスタンスへのClass<? extends DatabaseHelper>キーのハッシュマップです。

私がDAOキャッシュを必要とするのは、自分のグローバルキャッシュを使用しないで内部的に生成されたDAOによって複数の外部コレクションが読み込まれているためです。

私がこれを書いていたように、私は、私はちょうどDaoManager.createDao(...)に至るまで、私の上書きhelpy.getDao(...)電話を持っていると考えていたが、それは同じことになり:私はまだcreateDao(...)への2回目の呼び出しで異なるDAOを取得します。これは私には完全にDaoManagerのドキュメントに反対するようです。私は事前生成設定ファイルを使用していますので、

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); 
    } 

DaoManagerのソースのライン230上のreturnは(更新されてからclassMapを防止することを:

まず、私はそれが犯人かもしれregisterDao(...)のように見えたと思いました?)。私のコードが2回目の作成呼び出しに当たったら、最初にclassMapを見て、何らかの形で(私のより良い理解に対して)そこに住んでいるDAOの別のコピーを見つけます。最初の作成を進めるので、私はclassMapが初期化されるのを見ました。

しかし、2番目のDAOはどこから来るのでしょうか?

グレイの洞察を楽しみにしています! :-)

+0

ちょうどあなたの問題を解決しなければならないスナップショットリリースベンを押し出します。お知らせ下さい。 http://ormlite.com/releases/ – Gray

+0

テスト中です。私のカスタムDAOを今作成している例外を当て、それを調べます。 –

+0

'Store'で1対多の関係を持つ私のクラスの1つが、' FieldType:287'に例外をスローしています。 'dataPersister'は' IntType'のインスタンスなので、それは基本的な型だと考えていますか? 4.33の下でこれを見ていなかった。 –

答えて

0

@Benが述べたように、内部のDAO作成がありますが、バグを発見した可能性があります。 Androidの下で

は、ORMLite最新のAndroid OSのバージョンが、すべての下恐ろしい反射性能与えられたのDAOを構築するために、いくつかのマジックリフレクションを使用しようとします。ユーザーがクラスStore(たとえば)のDAOを要求すると、マジックリフレクションfuは1つのDAOを作成していますが、内部的に別のDAOを使用しています。私はDAOには、反射出力を使用してより良い仕事をするために作成されます方法を変更し

https://sourceforge.net/tracker/?func=detail&aid=3487674&group_id=297653&atid=1255989

:私は次のバグを作成しました。その変更は4.34で追い出された。このリリースでは、内部DAOの作成とキャッシングを改善(および簡素化)します。それは問題を解決するはずです。

http://ormlite.com/releases/

+0

必要な 'lookupDao'呼び出しに失敗したときに、' createDao'メソッドがクラスのDAOを作成中であることを登録できる 'DaoManager'にレジストリ(おそらく' HashSet') Xが実際の作成プロセスに入る前に未完成のDAOを参照したい(そして再帰プロセス中に生成される)従属DAOのリスナーは、再帰(および作成)が完了した時点で参照を設定することができますか? –

+0

私はそのようなレジストリを持っていますが、設定された手とアノテーションで設定されたクラスとの間に違いがあります。リフレクションコードは、手で構成されたクラスを使用し、したがって内部の混乱を使用します。 – Gray

0

ちょうど冗談です。私のStoreオブジェクトのDAO初期化は、外部接続(私はforeignAutoRefreshに設定されている)に対してDAOを作成していて、これを再帰的に別のDAOを作成しています。(これを開始したDAOの作成は完了せず、 DaoManagerと登録されています)。

これは、BaseDaoImpl.initialize()に記載されている再帰を伴っている必要があります。

私はInceptionのフラッシュバックを見ているだけです。