Discussion :

[peter27x]

Hello,

j'ai des objets de divers types, ils possèdent des pointeurs les uns vers les autres, tout marche très bien, ok.

Je vais devoir à terme pouvoir fermer l'appli tout en la sauvegardant en base de données (firebird a priori, que je ne connais pas), puis pouvoir rétablir l'appli à l'ouverture, à son dernier état, donc depuis la BD.

Ma question : quelles sont les meilleures méthodes pour enregistrer les "liens" inter objets, car un pointeur indique l'adresse mémoire d'un objet à un instant t, mais à un instant t+x cet objet aura une autre adresse mémoire.

Je peux envisager une solution, consistant à mémoriser en BD des identifiants uniques des objets pointés, dont je me servirai ensuite à la réouverture de l'appli pour reconstruire tout le jeu de pointeurs à chaque création d'objet stockés en BD...

Seulement je me demande s'il n'existe pas des solutions toute prête dans Delphi, et aussi si la fameuse classe TPersistent n'aurait pas quelque chose à voir avec ce genre de problématique ?

Merci à vous !

[philnext]

Je dirais que, justement, Delphi permet autant que possible d'éviter d'utiliser des pointeurs.
Le plus simple serait de remplacer ces pointeurs par 'autre chose' que tu pourrais alors sauvegarder.

[peter27x]

Je dirais que, justement, Delphi permet autant que possible d'éviter d'utiliser des pointeurs.
Le plus simple serait de remplacer ces pointeurs par 'autre chose' que tu pourrais alors sauvegarder.

Quand je dis "pointeur" c'est au sens "Delphi", c'est à dire une variable A d'un type T que je n'instancie par par A.create mais que je fais pointer sur un autre objet B de même type par A:= B.

Ce n'est pas un vrai pointeur du style A : ^T

Tu vois ?

[Paul TOTH]

j'ai traité ça dans un projet en gros j'avais des containers qui pointent sur des items qui pointent sur des items et des containers.

mais j'ai un TList de tous mes container et chaque container possède un TList des instances d'item. Du coup à la sauvegarde je renseigne le Count des list et les List.IndexOf() des instances.

à la lecture, grâce au count je crée toutes mes instances puis je lie les index pour les retrouver dans ma nouvelle liste.

[peter27x]

j'ai traité ça dans un projet en gros j'avais des containers qui pointent sur des items qui pointent sur des items et des containers.

mais j'ai un TList de tous mes container et chaque container possède un TList des instances d'item. Du coup à la sauvegarde je renseigne le Count des list et les List.IndexOf() des instances.

à la lecture, grâce au count je crée toutes mes instances puis je lie les index pour les retrouver dans ma nouvelle liste.

Oui, aussi, j'avais pensé à un moment donné à remplacer les pointeurs par des "index" correspondant à des emplacements dans des tableaux de pointeurs ! Ces tableaux pointeraient vers les objets, et évidemment, pour que tout ceci soit viable, l'ordre d'enregistrement et de lecture devraient coïncider et coïncider avec l'ordre d'indexation des tableaux, pour que l'ensemble reste cohérent.

C'est bien cela Maître Toth ?

[Paul TOTH]

oui c'est bien cela

dans mon code, j'ai deux listes qui se font références...la sauvegarde se fait selon mes besoins en lecture

1) je dois connaître le nombre d'instance de ma première liste, je crée les instances en fonction de ce nombre.
2) je peux créer les instances de ma seconde liste en faisant référence par index aux éléments de la première. Pour cela, chaque instance peut lire les infos dont elle a besoin dans mon stream et pointe sur les instances crées en 1.
3) je peux lire les infos des instances de ma première liste qui peuvent maintenant faire référence par index aux éléments de ma seconde liste.

[Kaféine]

Wahoo ca ma l'air compliqué tout ça :\

J'ai pas tous compris.

Quand je dis "pointeur" c'est au sens "Delphi", c'est à dire une variable A d'un type T que je n'instancie par par A.create mais que je fais pointer sur un autre objet B de même type par A:= B.

il y a forcément une instanciation à un moment non, surement de B? alors pourquoi ne pas serialiser l'objet B et le stocker...plutôt que de jouer avec le s pointeurs??

je ne comprend pas...

[peter27x]

Wahoo ca ma l'air compliqué tout ça :\

J'ai pas tous compris.



il y a forcément une instanciation à un moment non, surement de B? alors pourquoi ne pas serialiser l'objet B et le stocker...plutôt que de jouer avec le s pointeurs??

je ne comprend pas...

Je ne sais pas, je n'ai jamais utilisé le "serializable", que ce soit en Java ou en Delphi, ça peut paraître con, mais c'est un fait !

[Aka Guymelef]

La sérialisation apparait de manière différente dans chaque langage mais ce qu'il faut comprendre c'est la notion derrière.

Dire que quelque chose est sérialisable indique que ce quelque chose est transformable en un format qui peut être sauvegardé (sur disque, bdd, etc...) et surtout qui peut être relut et décodé pour revenir à l'objet originel.

Un exemple de sérialisation au quotidien avec Delphi c'est bien les fiches (et plus exactement tout les composants) qui sont sauvegardées dans les .dfm et lorsque tu ré-ouvres une fiche dans l'éditeur miracle tu retrouves tout tes composants avec toutes leurs propriétés dans l'état que tu les avais laissés lors de la dernière sauvegarde.

[peter27x]

La sérialisation apparait de manière différente dans chaque langage mais ce qu'il faut comprendre c'est la notion derrière.

Dire que quelque chose est sérialisable indique que ce quelque chose est transformable en un format qui peut être sauvegardé (sur disque, bdd, etc...) et surtout qui peut être relut et décodé pour revenir à l'objet originel.

Un exemple de sérialisation au quotidien avec Delphi c'est bien les fiches (et plus exactement tout les composants) qui sont sauvegardées dans les .dfm et lorsque tu ré-ouvres une fiche dans l'éditeur miracle tu retrouves tout tes composants avec toutes leurs propriétés dans l'état que tu les avais laissés lors de la dernière sauvegarde.

C'est facilement utilisable en Delphi ou bien est ce coriace à apprivoiser et à faire fonctionner correctement ?

[peter27x]

oui c'est bien cela

dans mon code, j'ai deux listes qui se font références...la sauvegarde se fait selon mes besoins en lecture

1) je dois connaître le nombre d'instance de ma première liste, je crée les instances en fonction de ce nombre.
2) je peux créer les instances de ma seconde liste en faisant référence par index aux éléments de la première. Pour cela, chaque instance peut lire les infos dont elle a besoin dans mon stream et pointe sur les instances crées en 1.
3) je peux lire les infos des instances de ma première liste qui peuvent maintenant faire référence par index aux éléments de ma seconde liste.

J'étais tout pimpant cher Paul puis paf! la sale idée : quid de la suppression d'un ou plusieurs éléments de nos chers tableaux de pointeurs... car si ce sont, comme je l'envisageais gaiement, des TObjectList, alors ils gèrent automatiquement la ré-indexation automatique de leurs entrées... d'où problème pour réaffecter tous les objets qui pouvaient avoir un ou plusieurs index vers ledit tableau, notamment index supérieurs à celui de l'élément supprimé (vu que ce sont ceux là qui vont être ré-indexés "vers le bas" ou "vers le haut" ça dépend comment on voit la chose )... chiant le truc non ?

[Paul TOTH]

J'étais tout pimpant cher Paul puis paf! la sale idée : quid de la suppression d'un ou plusieurs éléments de nos chers tableaux de pointeurs... car si ce sont, comme je l'envisageais gaiement, des TObjectList, alors ils gèrent automatiquement la ré-indexation automatique de leurs entrées... d'où problème pour réaffecter tous les objets qui pouvaient avoir un ou plusieurs index vers ledit tableau, notamment index supérieurs à celui de l'élément supprimé (vu que ce sont ceux là qui vont être ré-indexés "vers le bas" ou "vers le haut" ça dépend comment on voit la chose )... chiant le truc non ?

ben oui mais non

dans la sérialisation, les instances sont liées aux données sauvegardées...donc si tu supprimes un objet dans ta liste, soit tu recharges l'ancienne liste et la suppression n'est pas prise en compte, soit tu sauvegardes cette nouvelle liste et les indexes sont cohérents

en gros, un Load commence par un Clear, puis le flux déterminera s'il y a des instances à recréer

[peter27x]

ben oui mais non

dans la sérialisation, les instances sont liées aux données sauvegardées...donc si tu supprimes un objet dans ta liste, soit tu recharges l'ancienne liste et la suppression n'est pas prise en compte, soit tu sauvegardes cette nouvelle liste et les indexes sont cohérents

en gros, un Load commence par un Clear, puis le flux déterminera s'il y a des instances à recréer

Ha mince je ne savais pas quand tu me parlais de cette technique des tableaux de pointeurs c'était avec la technique de la sérialisation ! Tu ne m'en avais pas parlé (sauf erreur de ma part).

Je vois pas ce qui résoud mon problème dans ton texte ci dessous:
dans la sérialisation, les instances sont liées aux données sauvegardées...donc si tu supprimes un objet dans ta liste, soit tu recharges l'ancienne liste et la suppression n'est pas prise en compte, soit tu sauvegardes cette nouvelle liste et les indexes sont cohérents


Je pense que je vais devoir gérer la réindexation moi même avec 1 ou 2 petites routines (rien de bien sorcier dans l'absolu, juste de l'algorithmie bien torchée à sortir quoi... !).

EDIT: en fait je me complique la vie pour rien je crois... dans l'appli telle qu'elle est quand un objet pointé par un tiers est supprimé, le/les tiers sont déjà affectés (suppression du tiers), et je gère déjà certains "pointage" sans pointeur, mais juste avec des id uniques (des noms obligatoirement uniques dans certains cas...) et j'ai déjà des routines qui gèrent la pointage via ces id uniques... j'ai juste deux trois classes à arranger (ajouter des index en plus des pointeurs) pour que enregistrement en BD et restauration via la BD fonctionne nickel...

EDIT2 : en fait si je vais qd même devoir gérer la ré-indexation pour les index (de tiers) supérieurs à l'index supprimé, ou alors je dis à Delphi de pas ré-indexer ses tableaux TObjectList et donc de laisser nil dans les entrées supprimées... je sais pas si c'est possible.

EDIT3: après recherche ce n'est point possible, je dois moi même mettre nil à l'entrée voulue, puis supprimer moi même l'objet pointé par ladite entrée. Mais dans ce cas là on perd tout l'intérêt du TObjectList... dommage, ça ne me plait pas bcp ça...

[peter27x]

Pour info,

en fait la sérialisation n'est pas une solution interessante pour moi, je dois bien stocker des index afin de mémoriser / reconstruire la classe d'objet à volonté quelle que soit sa structure.

En fait l'appli sera distribuée à x clients, donc on devra pouvoir à tout moment (sav, interventions, upgrades...) récupérer la base de chacun ! Donc la sérialisation, à quoi elle me servirait ?

A moins que le client m'envoie la liste de tous les fichiers ".dfm" présents dans le répertoire où se trouve l'exécutable, c'est ça ? Et à moi ensuite de mettre ces ".dfm" dans un rep de mon pc contenant juste l'exécutable afin qu'il s'en serve pour reconstruire la structure des objets ?

M'enfin bon, vu qu'il y aura d'autres choses à stocker (profils, utilisateurs, param généraux...) je devrais de toute façon avoir une base de données, donc pas la peine de manipuler deux outils au lieu d'un seul.

[Kaféine]

en fait la sérialisation n'est pas une solution interessante pour moi, je dois bien stocker des index afin de mémoriser / reconstruire la classe d'objet à volonté quelle que soit sa structure.

la sérialisation te permet de stocker des objets, comme on te l'a dit précédemment, delphi le fait avec les composants stockés dans les dfm (c'est juste un exemple de sérialisation)

Rien ne t'empèche de serialisr et de stocker les objets dans un SGBD.

exemple simpliste:
imaginons un objet TIntervention...

instance de TIntervention => Serialisation => SGBD

SGBD => Désérialisation => instance de TIntervention

[peter27x]

la sérialisation te permet de stocker des objets, comme on te l'a dit précédemment, delphi le fait avec les composants stockés dans les dfm (c'est juste un exemple de sérialisation)

Rien ne t'empèche de serialisr et de stocker les objets dans un SGBD.

exemple simpliste:
imaginons un objet TIntervention...

instance de TIntervention => Serialisation => SGBD

SGBD => Désérialisation => instance de TIntervention

Cette méthode est elle prévue et donc optimisée sous Delphi/Firebird de manière à être plus interessante que de me taper une mise en BD à la mano ? (insert into table Toto values (..,..,..,..,.....) x fois) ?

[Kaféine]

Cette méthode est elle prévue et donc optimisée sous Delphi/Firebird de manière à être plus interessante que de me taper une mise en BD à la mano ? (insert into table Toto values (..,..,..,..,.....) x fois) ?

la sérialisation est plutôt simple à mettre en oeuvre avec Delphi. Aprés à toi de minimiser les accés BDD en factorisant ton code....de plus je suis persuadé que plein d'exemples existent sur le web.

[Aka Guymelef]

La sérialisation à aussi pour but d'agréger plusieurs informations en une seule (avec un format). Donc si tu stockes en base de donnée le résultat de la sérialisation tu ne manipule qu'une seule colonne (très grand) plutôt que autant de colonnes que de champs dans ta classe.

Cela à l'avantage certain que, si ton moteur de sérialisation est générique, l'ajout d'un champ dans la classe n'entraine aucune modification côté BDD.

[peter27x]

La sérialisation à aussi pour but d'agréger plusieurs informations en une seule (avec un format). Donc si tu stockes en base de donnée le résultat de la sérialisation tu ne manipule qu'une seule colonne (très grand) plutôt que autant de colonnes que de champs dans ta classe.

Cela à l'avantage certain que, si ton moteur de sérialisation est générique, l'ajout d'un champ dans la classe n'entraine aucune modification côté BDD.

Hummm pas mal pas mal... surtout la dernière phrase.

QUID de l'interrogation via une requête SQL portant sur une table de ce type ? Peut on attaquer tel ou tel champ distinctement comme avec une table classique à x colonnes ?

[Aka Guymelef]

Ben techniquement pour moi ce serait un [grand] champ texte (ien fait il vaudrait mieux un BLOB mais ici je ne vais pas te polluer avec les histoires de Stream pour y accéder/enregistrer ) et donc tu fais une requête standard qui va te ramener ton champ, tu récupère le string et tu désérialises.