Discussion :

[kegilko]

Bonjour =)

Je cherche un moyen pour avoir le _id max d'une table qui peut être vide.
Par exemple :
J'ai une table avec 3 rows (donc _id 1, _id 2, _id 3), l'application peut vider la table à tout moment via un boutton. Si la table est vidée, j'aimerais obtenir le _id row max (_id row max = 3 dans cet exemple) de cette table avant d'ajouter de nouvelles rows.

Estce possible ? si oui comment faire ?

Merci bien =)

[Minicalion]

Bonjour kegilko,

Est-ce que l'id que tu souhaite récupérer correspond à la clé primaire de la table?
Si oui, pourquoi souhaite tu récupérer l'_id max d'une table qui n'existe plus?

Une façon de procéder serait de récupérer cette idée avant la suppression de la table, en utilisant un curseur.
Lors de la création de ce curseur, si on ne spécifie aucun "filtre", alors le curseur donne accès à toute la table, il ne reste plus qu'à le placer à la fin de la table, et demander l'_id de cet élément.

Mais si cet id correspond à la clé primaire de la table, alors je ne vois pas trop l'intérêt de connaître la dernière clé d'un table qui n'existe plus. pourrais tu nous fournir plus de précision sur ce que tu souhaite faire?

[kegilko]

En fait, j'ai une appli sur laquelle on enregistre des fiches. Elles sont stockées localement (sqlite..), et peuvent être envoyé sur une base de données distante.
Le truc c'est que ces fiches peuvent être lourdes (elles contiennent des photos..), donc j'ai implémenté une fonction qui permet via un bouton de supprimer les fiches du téléphone qui ont déjà été stocké dans la bdd distante.

Par comodité, chaque fois que l'on souhaite créér une fiche, un formulaire apparait avec le numéro de la fiche (c'est ici que le _id joue) et une fois ce formulaire validé il est enregistré dans la base sqlite du smartphone.

Donc jusqu'à maintenant, je lisais le nombre de row de la table pour connaitre le numéro de la fiche. Mais maintenant qu'on peut vider toute la table, le numéro de fiche va repartir à zero si je me contente de lire le nombre de row..et ce n'est pas ce que je veux.

D'autant plus que lorsqu'une nouvelle fiche est créé après que la table a été vidée, le _id de cette fiche ne se réinitialise pas à 0 (ce qui m'arrange..). Donc si le _id ne s'est pas réinitialisé à zéro, c'est qu'il doit bien être stocké quelque part où je pourrais l'avoir ?

J'espère avoir été clair ^^

[Minicalion]

Ok, je comprends mieux.

Je ne sais absolument pas où peut bien être stocké cette information, et encore moins comment la récupérer. Désolé. Cependant, la méthode que je t'ai proposé précédemment, permet d'aboutir au résultat que tu souhaite.

J'espère que quelqu'un passera par là avec plus d'informations.

[kegilko]

Le soucis est que si un utilisateur quitte l'appli après avoir vidé la table, et qu'il revient... le curseur qui a servis pour enregistré n'existera plus..

Bon, la solution je la voie hein, il faudrait que je stock la valeur quelque part avant suppression de la table. Mais je ne vais tout de même pas stocker une malheureuse peite variable dans une table exprés pour elle... Avant d'obtenir 'la' solution 'propre', quel est le moyen le plus simple de stocker une information type int qui persiste dans le smartphone ?

Je vais recherché dans ce sens..

[Minicalion]

Stocké cette variable dans la base de donnée n'est pas interdit.

Après, stocker des informations de manière persistante il y a plusieurs façon de procéder, l'utilisation d'un fichier, ou d'objet mis à disposition par le framework.

Tiens, un coup de pouce pour trouver une solution qui te convient:

http://developer.android.com/guide/t...a-storage.html

[nicroman]

Si, comme recommandé, '_id' est un "primary key interger autoincrement", alors il est mappé automatiquement par sqlite sur rowid, et c'est la valeur qu'on reçoit lors d'un insert (sans _id).

Donc:

nouvelle fiche => database.insert (sans la colonne _id) qui va renvoyer le _id attribué justement.
envoi sur le serveur => on utilise l'_id
destruction locale => database.delete(_id)
copie serveur vers local => database.insert (avec la colonne _id précédente).

Donc on n'a jamais besoin de connaitre le "prochain _id".

[kegilko]

alors il est mappé automatiquement par sqlite sur rowid

Hmm et du coup il n'est pas possible de récupérer d'une manière ou d'une autre l'id localement même depuis une table vide ?

et

nouvelle fiche => database.insert (sans la colonne _id) qui va renvoyer le _id attribué justement.
envoi sur le serveur => on utilise l'_id
destruction locale => database.delete(_id)
copie serveur vers local => database.insert (avec la colonne _id précédente).

J'y ai pensé, et hormis le fait que je trouve ça assez lourds il y a un cas d'utilisation que je souhaite respecter (parce que ça va arriver souvent avec mon appli) et qui ne pourra se faire avec la méthode au dessus (je vais passer pour le roi des chieurs x) ) :
- Si l'utilisateur créé des fiches , sature ça mémoire et se retrouve dans un coin sans Internet. Il va vider les données déjà envoyées auparavant et à ce moment là, faute de pouvoir se connecter il ne pourra pas récupérer la variable stockée sur la base de données en ligne :/

Bon, après avoir vagué sur la toile je n'ai pas le choix a priori, je doit stocker en local la valeur... j'ai le choix entre creer une nouvelle table sqlite qui ne sera jamais vidée (mais je trouve ça vraiment gros x) ) ou sinon passer par les SharedPreferences, je vais opter pour ces derniers.

Merci pour vos coup de pattes en tout cas =)

[nicroman]

Je crois qu'on s'est mal compris... je ne parlais pas de stocker l'id sur un serveur distant.... mais la fiche entière quand l'utilisateur n'en veut plus en "local".

Ou alors je n'ai vraiment pas compris le but du truc, je ne vois toujours pas l’intérêt de connaitre *A L'AVANCE* l'id attribué à une "fiche".
Serait-il possible d'avoir un "use-case" ?

Parce que si j'ai bien compris, le seul interèt est d'afficher un identifiant à l'utilisateur (un truc qui lui passe bien au dessus de la tête et dont il se fiche à priori éperdument, donc dont on peut parfaitement se passer).

Si c'est absolument nécessaire, coller une colonne "numéro de fiche" dans la table (indépendamment de l'_id utilisé en interne pour référencer la fiche) et utiliser n'importe quelle stratégie locale pour incrémenter cet identifiant de manière unique et atomique (atomique avec la transaction en database en tout cas).

[kegilko]

C'est bien l'idée oui. En fait, l'appli sera utiliée en pleine nature le plus souvent donc Internet, niet ^^
Et du coup, si l'utilisateur créé une nouvelle fiche je suis obligé de dégoter le numéro localement..donc à partir de la, il y a différentes stratégie dont celles que vous avez évoquées.

Parce que si j'ai bien compris, le seul interèt est d'afficher un identifiant à l'utilisateur (un truc qui lui passe bien au dessus de la tête et dont il se fiche à priori éperdument, donc dont on peut parfaitement se passer).

Je ne peux pas te donner tord..