Discussion :

[soft0613]

Bonjour à tous, je m'exerce à écrire un programme en Java où je dois écrire des données sur le disque dur afin de les sauvegarder entre 2 executions du programme et ma question est la suivante.

Cela pose-t-il des problème si je stocke mes données dans un objet Java unique (qui sera donc de taille conséquente) que j'écris ensuite sur le disque ou est-il préférable de créer moi même des dossiers afin d'y enregistrer les données séparément.

Si j'opte pour la permière option j'aruais aimé savoir si un objet référence à plusieurs endroit sera bien unique une fois le fichier chargé.

Si j'opte pour la deuxième option l'avantage est que je peux sauvegarder mes données séparément sans avoir à réécrire tout l'objet qui contient l'état de mon programme, le problème est que cette fois je sais que je dois me débrouiller pour ne pas référencer un objet à deux endroits différents ou il y aura une création de doublons une fois le programme relancé.

Voilà si vous voyez d'autre avantages/inconvéniant permettant d'éclairer mon choix merci de m'apporter vos idées et éclairsissements.

À bientôt.

[tchize_]

tous dépend de la quantité de données. D'abord, il faudra que toutes tes données soient sérializable. Ensuite, il faut etre conscient qu'avec la sérialisation, la désérialisation nécessite les memes classes, ce qui pourrait te poser un problème lors de mises à jours de ton programmes (problème qui peut etre contourné en utilisant correctement l'interface externalizable et en s'assurant de bien gérer les cas possibles d'upgrade, par exemple en stockant le numéro de version des classes)

pour l'unicité et les références croisées, le processus de serialization en tiens déjà compte, tant que tu reste au sein d'un meme objectOutputStream (et vis-versa ObjectInputStream), les références resteront maintenues. La sérialisation fait attention à ne pas dupliquer.

[tchize_]

une option peut etre intéressante serait d'utiliser un mapping style hibernate et une base de données embarquées.

[soft0613]

Merci de l'intérêt que tu portes à ma demande, je ne connais pas hibernate je vais me documenter... aurais-tu quelques pistes de recherche dans ce sens ?

Sinon en ce qui concerne la taille des données il s'agit d'un genre d'agenda, on peut y entrer des contacts avec adresse, numéro... qui sont contenu dans des groupes (travail, famille... par exemple) donc il peut y en avoir beaucoup c'est pour ça que je trouve un peu lourd de devoir enregistrer tout l'état pour avoir modifier uniquement le nom d'un contact.

[tchize_]

pour des agenda, peut etre qu'utiliser un des format standard existant serait plsu approprié, et compatible avec les autres applications existantes, comme par exemple te baser sur du vcard: http://en.wikipedia.org/wiki/VCard

[soft0613]

Merci du lien je ne connaissais pas, mais étant donné que je fais ça dans un but d'apprentissage du langage, le contenu du logiciel n'est pas d'une importance cruciale et je préfère me concentrer sur Java vu que je n'ai pas trop de connaissances sur tout ces standard... je me dis "chaque chose en son temps".

[gifffftane]

Cela pose-t-il des problème si je stocke mes données dans un objet Java unique (qui sera donc de taille conséquente) que j'écris ensuite sur le disque ou est-il préférable de créer moi même des dossiers afin d'y enregistrer les données séparément.

Non, cela ne pose pas de problèmes. Si la seule raison est d'enregistrer les données séparément, ne le fait pas. Tu as des objets, tu les enregistres, s'ils te paraissent trop gros ( ? ) tu réfléchis à ta conception et à tes conceptions objets, etc. Ignore le disque dur.

Si j'opte pour la permière option j'aruais aimé savoir si un objet référence à plusieurs endroit sera bien unique une fois le fichier chargé.

Oui, un objet référencé à plusieurs endroits ne sera enregistré qu'une seule fois, s'il est enregistré par le même flux de sérialisation ; donc, lorsque tout est contenu dans un gros objet unique enregistré : oui.

Si j'opte pour la deuxième option l'avantage est que je peux sauvegarder mes données séparément sans avoir à réécrire tout l'objet qui contient l'état de mon programme, le problème est que cette fois je sais que je dois me débrouiller pour ne pas référencer un objet à deux endroits différents ou il y aura une création de doublons une fois le programme relancé.

Ce problème se résoudra en mettant en place une re-génération, une re-fabrication de ton appli. Mais si tu débutes en java, je pense qu'il vaut mieux que tu évites cette approche. Chaque chose en son temps.

Il vaut mieux te concentrer sur ce qui est vraiment utile à sauvegarder, et comment cette chose s'organise.

Bon développement.

[soft0613]

Merci de vos réponses, en fait je ne débute pas vraiment ça fait déjà quelques temps que je pratique.

Je n'arrivais pas à m'en sortir alors j'ai pris le problème différement (l'idée m'es venue quand j'ai lu ce qu'a mis giffffftane sur la re-génération).

En fait je pense séparer l'objet créer un simulacre des données de mon programme dans des objets implémentant Serializable, puis recharger les données de mon programme à partir de ces objets.

Pour ce qui est des références multiples à un seul objets dans diverses donnée du programme je pense associer à chaque objet une valeur de hachage spécifique (en partant de 1 et en incrémentant de 1 pour chaque objet créé) et les conserver dans une seule collection, ensuite je ne mémorise que des "pointeurs" qui contiennent la valeur de hachage me permettant de récupérer l'objet au sein de la collection, ainsi je n'ai plus de problèmes de doublons.

J'ai fais un petit calcul pour essayé d'estimer la limite offerte par l'utilisation d'un int pour identifier un objet, la plage des int que j'utilise va de 1 à Integer.MAX_VALUE (environ 2 millions), donc en créant un objet toutes les secondes il me faudra 160 ans avant de devoir perfectionner le système, donc ça ne pose pas problème de ce côté là.

Pensez-vous que se soit une bonne idée ? ou y a-t-il une approche plus simple (sans utiliser trop d'outils préconçu car je souhaite plutôt perfectionner ma pratique du langage et non produire quelque chose dont je ne saisirais pas tous les détails en raison de l'utilisation de bibliothèques externes).

[gifffftane]

C'est toujours la limite entre inventer pour la millième fois le fil à couper le beurre pour des raisons d'auto-formation ou utiliser des trucs déjà existants pour que ça aille plus vite.

À toi de voir...

Attention que le hashage n'est pas censé perdurer d'une sérialization à une autre, comme l'explique je ne sais plus quelle javadoc. Je crois que le UUID est plus indiqué pour ça... à moins que tu ne veuilles également re-inventer le concept ?

Et, si, comme il est fort judicieux, tu ne sauvegarderas que des simulacres de données, peut être pourras-tu t'intéresser (en plus des technos qui t'ont déjà été données) au JSR 170: Content Repository for JavaTM technology API et à jackrabbit, j'ai l'impression que cela correspond particulièrement bien à ta problématique.

[soft0613]

En fait je pensais avoir un générateur de hash-code autonome ou je mémoriserais la dernière valeur utilisée dans un fichier, car oui sinon le hachage par défaut ne perdure pas.

Merci bien pour toutes ces infos et le temps que t'as passé à répondre, je vais aller potasser les liens que tu m'as donné en espérant y trouver des infos utiles.

À bientôt.