Bonjour, autre question concernant Hibernate et plus généralement la
persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de
question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour
résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la
base, mais que pour économiser la mémoire, quand des objets sont
inutilisés, il les enlève et ne les recharge que si on essaye de
réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je
risque d'insérer des bugs avec perte de données si y'a des update() qui
se font par la suite...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier MOGHRABI
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire + "caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les relations de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
-- Xavier MOGHRABI - Consortium ObjecWeb
Pif wrote:
Bonjour, autre question concernant Hibernate et plus généralement la persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la base, mais que pour économiser la mémoire, quand des objets sont inutilisés, il les enlève et ne les recharge que si on essaye de réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je risque d'insérer des bugs avec perte de données si y'a des update() qui se font par la suite...
Des suggestions ?
Merci.
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire +
"caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les relations
de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
--
Xavier MOGHRABI - Consortium ObjecWeb
Pif wrote:
Bonjour, autre question concernant Hibernate et plus généralement la
persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de
question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour
résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les
infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la
base, mais que pour économiser la mémoire, quand des objets sont
inutilisés, il les enlève et ne les recharge que si on essaye de
réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je
risque d'insérer des bugs avec perte de données si y'a des update() qui
se font par la suite...
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire + "caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les relations de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
-- Xavier MOGHRABI - Consortium ObjecWeb
Pif wrote:
Bonjour, autre question concernant Hibernate et plus généralement la persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la base, mais que pour économiser la mémoire, quand des objets sont inutilisés, il les enlève et ne les recharge que si on essaye de réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je risque d'insérer des bugs avec perte de données si y'a des update() qui se font par la suite...
Des suggestions ?
Merci.
ludo06
Xavier MOGHRABI wrote:
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire + "caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les relations de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
(Cela existe aussi sous OJB, sous la forme d'un attribut dans le
descripteur de collection par exemple) Dans le cas d'OJB que je connais mieux qu'hibernate, il y a differentes techniques de cache qui peuvent peut aussi t'etre utile et pour economiser la memoire les pools d'objets (bien souvent combines aux caches).
Dans un style plus barbare, que j'ai implemente en partie pour OJB, tu peux manipuler la couche ORM pour ne rechercher que les proprietes qui t'interessent dans les objets, dans le cas d'OJB en recreeant le descripteur de deploiement a l'execution avec uniquement les proprietes/ champs qui t'interesse (cela permet de choisir ce que tu prends parmis tout : proprietes simples, foreign key et collection). Evidemment des que tu t'interesse a des lignees d'objets et des filtres elabores ca devient complique a implementer soi meme. Je ne sais pas si hibernate fait des "filtres" de ce type, mais ca m'interesserais de savoir.
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire +
"caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les relations
de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
(Cela existe aussi sous OJB, sous la forme d'un attribut dans le
descripteur de collection par exemple)
Dans le cas d'OJB que je connais mieux qu'hibernate, il y a differentes
techniques de cache qui peuvent peut aussi t'etre utile et pour
economiser la memoire les pools d'objets (bien souvent combines aux caches).
Dans un style plus barbare, que j'ai implemente en partie pour OJB, tu
peux manipuler la couche ORM pour ne rechercher que les proprietes qui
t'interessent dans les objets, dans le cas d'OJB en recreeant le
descripteur de deploiement a l'execution avec uniquement les proprietes/
champs qui t'interesse (cela permet de choisir ce que tu prends parmis
tout : proprietes simples, foreign key et collection). Evidemment des
que tu t'interesse a des lignees d'objets et des filtres elabores ca
devient complique a implementer soi meme. Je ne sais pas si hibernate
fait des "filtres" de ce type, mais ca m'interesserais de savoir.
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire + "caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les relations de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
(Cela existe aussi sous OJB, sous la forme d'un attribut dans le
descripteur de collection par exemple) Dans le cas d'OJB que je connais mieux qu'hibernate, il y a differentes techniques de cache qui peuvent peut aussi t'etre utile et pour economiser la memoire les pools d'objets (bien souvent combines aux caches).
Dans un style plus barbare, que j'ai implemente en partie pour OJB, tu peux manipuler la couche ORM pour ne rechercher que les proprietes qui t'interessent dans les objets, dans le cas d'OJB en recreeant le descripteur de deploiement a l'execution avec uniquement les proprietes/ champs qui t'interesse (cela permet de choisir ce que tu prends parmis tout : proprietes simples, foreign key et collection). Evidemment des que tu t'interesse a des lignees d'objets et des filtres elabores ca devient complique a implementer soi meme. Je ne sais pas si hibernate fait des "filtres" de ce type, mais ca m'interesserais de savoir.
Bonjour, autre question concernant Hibernate et plus généralement la persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la base, mais que pour économiser la mémoire, quand des objets sont inutilisés, il les enlève et ne les recharge que si on essaye de réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je risque d'insérer des bugs avec perte de données si y'a des update() qui se font par la suite...
Des suggestions ?
Merci. Xavier MOGHRABI wrote:
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire + "caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les relations
de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
(Cela existe aussi sous OJB, sous la forme d'un attribut dans le
descripteur de collection par exemple) Dans le cas d'OJB que je connais mieux qu'hibernate, il y a differentes techniques de cache qui peuvent peut aussi t'etre utile et pour economiser la memoire les pools d'objets (bien souvent combines aux caches).
Dans OJB toujours, mais c'est aussi dans JDBC 3 si je dis pas de betise, tu peux scroller sur les resultats, ce qui evite de tous les materialiser (les RsIterator dans OJB).
Dans un style plus barbare, que j'ai implemente en partie pour OJB, tu peux manipuler la couche ORM pour ne rechercher que les proprietes qui t'interessent dans les objets, dans le cas d'OJB en recreeant le descripteur de deploiement a l'execution avec uniquement les proprietes/ champs qui t'interesse (cela permet de choisir ce que tu prends parmis tout : proprietes simples, foreign key et collection). Evidemment des que tu t'interesse a des lignees d'objets et des filtres elabores ca devient complique a implementer soi meme. Je ne sais pas si hibernate fait des "filtres" de ce type, mais ca m'interesserais de savoir.
Bonjour, autre question concernant Hibernate et plus généralement la
persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de
question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour
résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la
base, mais que pour économiser la mémoire, quand des objets sont
inutilisés, il les enlève et ne les recharge que si on essaye de
réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je
risque d'insérer des bugs avec perte de données si y'a des update() qui
se font par la suite...
Des suggestions ?
Merci.
Xavier MOGHRABI wrote:
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire +
"caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les
relations
de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
(Cela existe aussi sous OJB, sous la forme d'un attribut dans le
descripteur de collection par exemple)
Dans le cas d'OJB que je connais mieux qu'hibernate, il y a differentes
techniques de cache qui peuvent peut aussi t'etre utile et pour
economiser la memoire les pools d'objets (bien souvent combines aux caches).
Dans OJB toujours, mais c'est aussi dans JDBC 3 si je dis pas de betise,
tu peux scroller sur les resultats, ce qui evite de tous les
materialiser (les RsIterator dans OJB).
Dans un style plus barbare, que j'ai implemente en partie pour OJB, tu
peux manipuler la couche ORM pour ne rechercher que les proprietes qui
t'interessent dans les objets, dans le cas d'OJB en recreeant le
descripteur de deploiement a l'execution avec uniquement les proprietes/
champs qui t'interesse (cela permet de choisir ce que tu prends parmis
tout : proprietes simples, foreign key et collection). Evidemment des
que tu t'interesse a des lignees d'objets et des filtres elabores ca
devient complique a implementer soi meme. Je ne sais pas si hibernate
fait des "filtres" de ce type, mais ca m'interesserais de savoir.
Bonjour, autre question concernant Hibernate et plus généralement la persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la base, mais que pour économiser la mémoire, quand des objets sont inutilisés, il les enlève et ne les recharge que si on essaye de réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je risque d'insérer des bugs avec perte de données si y'a des update() qui se font par la suite...
Des suggestions ?
Merci. Xavier MOGHRABI wrote:
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire + "caching" pour optimiser l'accès aux données).
Je crois qu'Hibernate propose cette fonctionnalité mais pour les relations
de 1:N (donc pour les collections). Cela doit être expliqué dans la doc.
Cela doit également exiter sur d'ORM.
(Cela existe aussi sous OJB, sous la forme d'un attribut dans le
descripteur de collection par exemple) Dans le cas d'OJB que je connais mieux qu'hibernate, il y a differentes techniques de cache qui peuvent peut aussi t'etre utile et pour economiser la memoire les pools d'objets (bien souvent combines aux caches).
Dans OJB toujours, mais c'est aussi dans JDBC 3 si je dis pas de betise, tu peux scroller sur les resultats, ce qui evite de tous les materialiser (les RsIterator dans OJB).
Dans un style plus barbare, que j'ai implemente en partie pour OJB, tu peux manipuler la couche ORM pour ne rechercher que les proprietes qui t'interessent dans les objets, dans le cas d'OJB en recreeant le descripteur de deploiement a l'execution avec uniquement les proprietes/ champs qui t'interesse (cela permet de choisir ce que tu prends parmis tout : proprietes simples, foreign key et collection). Evidemment des que tu t'interesse a des lignees d'objets et des filtres elabores ca devient complique a implementer soi meme. Je ne sais pas si hibernate fait des "filtres" de ce type, mais ca m'interesserais de savoir.
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire + "caching" pour optimiser l'accès aux données).
Le cache va au contraire garder des objets en mémoire, ce qui semple être l'inverse du but recherché. Attention avec hibernate au paramètre hibernate.max_fetch_depth qui permet de monter en mémoire un graphe d'objets. Depuis hibernate 3, il me semble que le lazy loading est activé par défaut, et que outer-join est à false par défaut. Il ne devrait donc pas y avoir de problème.
Xavier MOGHRABI wrote:
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire
+ "caching" pour optimiser l'accès aux données).
Le cache va au contraire garder des objets en mémoire, ce qui semple être
l'inverse du but recherché.
Attention avec hibernate au paramètre hibernate.max_fetch_depth qui permet
de monter en mémoire un graphe d'objets.
Depuis hibernate 3, il me semble que le lazy loading est activé par défaut,
et que outer-join est à false par défaut.
Il ne devrait donc pas y avoir de problème.
Je pense que tu cherches typiquement à faire du "lazy-loading" (voire + "caching" pour optimiser l'accès aux données).
Le cache va au contraire garder des objets en mémoire, ce qui semple être l'inverse du but recherché. Attention avec hibernate au paramètre hibernate.max_fetch_depth qui permet de monter en mémoire un graphe d'objets. Depuis hibernate 3, il me semble que le lazy loading est activé par défaut, et que outer-join est à false par défaut. Il ne devrait donc pas y avoir de problème.
Fabien Bergeret
Pif wrote:
Bonjour, autre question concernant Hibernate et plus généralement la persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la base, mais que pour économiser la mémoire, quand des objets sont inutilisés, il les enlève et ne les recharge que si on essaye de réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je risque d'insérer des bugs avec perte de données si y'a des update() qui se font par la suite...
Des suggestions ?
Merci. Le 'lazy' peut se faire au niveau d'une relation, mais aussi au niveau
d'une classe, de telle sorte que toute relation (quelle que soit sa cardinalite) aboutissant a cette classe soit "lazy" ; il suffit pour cela, dans le fichier de mapping de la classe, de faire <class ... proxy="nomDeLaClasse">
Le principe de fonctionnement, c'est que l'objet pointe n'est reellement initialise (donc remonte de la base) que lorsque l'on en a besoin, c'est a dire lorsqu'on fait appel a une methode non statique ...
Pif wrote:
Bonjour, autre question concernant Hibernate et plus généralement la
persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de
question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour
résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la
base, mais que pour économiser la mémoire, quand des objets sont
inutilisés, il les enlève et ne les recharge que si on essaye de
réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je
risque d'insérer des bugs avec perte de données si y'a des update() qui
se font par la suite...
Des suggestions ?
Merci.
Le 'lazy' peut se faire au niveau d'une relation, mais aussi au niveau
d'une classe, de telle sorte que toute relation (quelle que soit sa
cardinalite) aboutissant a cette classe soit "lazy" ; il suffit pour
cela, dans le fichier de mapping de la classe, de faire
<class ... proxy="nomDeLaClasse">
Le principe de fonctionnement, c'est que l'objet pointe n'est reellement
initialise (donc remonte de la base) que lorsque l'on en a besoin, c'est
a dire lorsqu'on fait appel a une methode non statique ...
Bonjour, autre question concernant Hibernate et plus généralement la persistence :
j'ai une base de données qui est énorme (100 Go). Il est hors de question de tout avoir en mémoire. Il s'agit d'un gros "graphe" pour résumé.
Je dois donc naviguer dedans sans pour autant conserver toutes les infos...
J'aimerais savoir s'il y a un moyen de faire en sorte que je manipule la base, mais que pour économiser la mémoire, quand des objets sont inutilisés, il les enlève et ne les recharge que si on essaye de réaccéder en lecture aux objets. Je sais pas si c'est clair...
L'option de mettre des null pour les enlever n'est pas top, car je risque d'insérer des bugs avec perte de données si y'a des update() qui se font par la suite...
Des suggestions ?
Merci. Le 'lazy' peut se faire au niveau d'une relation, mais aussi au niveau
d'une classe, de telle sorte que toute relation (quelle que soit sa cardinalite) aboutissant a cette classe soit "lazy" ; il suffit pour cela, dans le fichier de mapping de la classe, de faire <class ... proxy="nomDeLaClasse">
Le principe de fonctionnement, c'est que l'objet pointe n'est reellement initialise (donc remonte de la base) que lorsque l'on en a besoin, c'est a dire lorsqu'on fait appel a une methode non statique ...
