Avis sur GreenDAO

Version imprimable

27/02/2013, 15h08
Arno5788

Avis sur GreenDAO

Bonjour,

Je cherchais une librairie pour simplifier l'utilisation de SQLite (j'étais même motivé pour en créer une) et je suis tombé sur GreenDAO.

Bizarrement, je n'ai pas trouvé beaucoup de retour d'utilisateurs de cette librairie et je voulais savoir si certains d'entre vous connaissent pour avoir leur point de vue.
27/02/2013, 16h14
nicroman

J'avoue n'avoir jamais essayé....

Et en tant que grand amateur de Hibernate, j'ai fait un hibernate-like-lite :mouarf: à base d'annotations... par contre, comme toujours, la gestion des versions est compliquée et pas automatique....
Je peux éventuellement cleanuper le code et le releaser si quelqu'un est vraiment interessé.
Au passage, pas sur que cela simplifie SQLite quand on a 3 tables qui se courent après.
27/02/2013, 17h31
Arno5788

Effectivement c'est pas forcément indispensable pour toutes les applications. A vrai dire, c'est surtout l'aspect "esthétique" qui m'interpelle. Ma DB possède une dizaine de tables et la classe java qui la gère fait 700 lignes, c'est un gros pâté un peu moche et pas franchement lisible.

J'avais pensé à un fonctionnement style Jackson, la librairie qui parse le JSON. On passe en paramètre un objet, un type, le path de la DB et il s'occupe du reste. Mais c'est vrai qu'avec des annotations ça peut être bien aussi

En fait l'idée est la suivante:

On a des POJOs représentant la DB:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
@SQLiteDatabase(MyDatabase)
@SQLiteTable(Livres)
class Livre
{
     private Long id;
     private String title;
     private String isbn;
     private Editeur editor;
 
     @SQLitePrimaryKey
     @SQLiteColumn(_ID)
     public void setId(Long id)
     {
         this.id = id;
     }
 
     @SQLiteColumn(TITLE)
     public void setTitle(String t)
     {
         this.title = t;
     }
 
     @SQLiteColumn(ISBN_CODE)
     public void setISBN(String i)
     {
         this.isbn = i;
     }
 
     @SQLiteForeignKey(EDITOR_ID)
     public void setEditor(Editeur e)
     {
         this.editor = e;
     }
 
     .. + les getters bien sur ..
}

Et ensuite... dans le code... on va juste faire un:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
    SQLiteSession session = SQLiteSession.current(); // thread-based.
    Livre lv = session.get(Livre.class,23); // va faire le select du livre #23... si déja en mémoire, va retourner l'instance directement
    // a noter que grace aux annotations, on sait à quelle DB ça correspond, quelle table, etc...
    // gestion des "nested" transaction... comme la session est thread-base, pas besoin d'utiliser un objet de transaction
    session.startTransaction();
    try {
        lv.setTitle(newTitle);
        session.save(lv); // on detecte l'ID, donc on fait un "update", sinon on aurait fait 'insert'
        session.commit();
    } finally {
        session.endTransaction(); // rollback si erreur !
    }

Pour l'instant là ou je galère c'est la gestion des auto-fetch lors des queries velues... mais comme je n'en ai pas besoin personnellement, je ne m'y investit pas trop en ce moment.
Et puis contrairement à hibernate, pas de data-cache level 1, pas d'interceptor pour savoir si un objet a été modifié ou non...

28/02/2013, 08h45
Arno5788

Je vois l'idée, ça peut déjà être pas mal pour mon cas. Merci bien
28/02/2013, 22h49
atha2

Il y a aussi ORMLite qui existe pour android : http://ormlite.com/sqlite_java_android_orm.shtml
01/03/2013, 01h11
nicroman

Ouais, mais j'aimais pas trop sa manière de gérer les transactions / exceptions. Et il ramenait tout un tas de code pour supporter les bases SQL JDBC dont on n'a que faire (en particulier pour les data-types) et il ne permettait pas l'utilisation d'objet Java particuliers (enums, ...).

Mais c'est clairement une option possible.