Discussion :

[Arno5788]

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.

[nicroman]

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

Et en tant que grand amateur de Hibernate, j'ai fait un hibernate-like-lite à 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.

[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

[nicroman]

En fait l'idée est la suivante:

On a des POJOs représentant la DB:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[Arno5788]

Je vois l'idée, ça peut déjà être pas mal pour mon cas. Merci bien

[atha2]

Il y a aussi ORMLite qui existe pour android : http://ormlite.com/sqlite_java_android_orm.shtml

[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.