Quick links: Content - sections - sub sections
EN FR
Quick Search Advanced search
 
Page

  [Opened] DAORecords et optional foreign tables

Posted by galves on 06/07/2006 10:23

La question cette fois ci est relative à l'utilisation des jDAORecords pour lire les valeurs contenues dans les optional foreign tables. Le résultat d'une requête, findAll() au hasard, renvoie un ensemble de records. Pour chacun de ces records, l'ensemble des valeurs le constituant est présente, une et une seule fois. Pas de problème pour la primary table ou une foreign table, mais la cardinalité d'une optional foreign table est potentiellement multiple. Y'a-t'il une façon simple d'avoir dans le record l'ensemble des valeurs matchant la foreign_key?

Ou alors faut-il se faire ça à la main avec des conditions ?

Si c'est le cas, on pourrait par exemple imaginer que les champs provenant d'une optional foreign table soient des tableaux, ou alors une méthode next() pour charger les valuers suivantes ...

Mais peut-être que tout cela sera expliqué dans le bout de doc manquant sur les daos ;)

  [Opened] Re: DAORecords et optional foreign tables

Reply #1 Posted by laurentj on 06/07/2006 13:43

mais la cardinalité d'une optional foreign table est potentiellement multiple

euh non.. optional foreign table, est comme son nom l'indique, une table étrangère optionnel. C'est à dire que tu as un champ dans ta table principal, contenant null ou la valeur identifiant d'un enregistrement d'une autre table. Tu as donc sur ta table principale, une jointure externe. (LEFT OUTER JOIN, ou (+)= sous oracle)

Donc la cardinalité est soit 0, soit 1. Mais pas plus de 1.

Donc, dans ton record, les champs correspondant à la foreigntable sont soit remplis ( la jointure a été satisfaite), soit vides (clé étrangère à null)

  [Opened] Re: DAORecords et optional foreign tables

Reply #2 Posted by galves on 06/07/2006 14:08

OK, je n'avais pas compris ce qu'était une optional foreign table (je ne suis pas très expert en bases de données :o/ ) Donc on change la question, on revient plus haut niveau. Le but est de créer un système de gestion de news et de leur traduction. J'ai deux tables, une news_base qui contient la date, l'url et la page de destination, et une news_text qui contient l'id de la news_base correspondante, la langue, le titre et le contenu de la news; dans la langue donnée. Donc j'ai potentiellement plusieurs news_text attachés à un news_base.

Ce que je veux dans un premier temps, c'est lister l'ensemble des news dans news_base et donner la liste des traductions disponibles.

Je voix deux possibilités: 1/Je travaille sur la table news_text et je dis que news_base est une foreign table. Le problème est que je dois ensuite parcourir tous les records pour les grouper par news identique. 2/Je gère la connection moi même, avec deux dao différentes, en utilisant des conditions

Existe -t'il une meilleure façon de faire ?

J'aurais aimé avoir la possibilité d'indiquer dans une dao une foreign table a cardinalité multiple; ce qui ce traduirait dans les record par des tableaux. Mais j'en demande peut-être trop ;)

  [Opened] Re: DAORecords et optional foreign tables

Reply #3 Posted by obi on 06/07/2006 14:59

Le risque est que la taille de ces tableaux est potentiellement grande, les remplir systématiquement à chque requête peut mettree un sacré coup aux performances. On peut plutôt imaginer ajouter un champ qui serait une factory avec une méthode supplémentaire auto-générée linkedToParent(), ou qqchose du style. Sinon, ça se fait assez bien à la main.

  [Opened] Re: DAORecords et optional foreign tables

Reply #4 Posted by laurentj on 06/07/2006 18:02

galves: le plus simple semble en effet de faire à la main, de jongler avec tes deux daos. D'ailleurs, je ne vois pas comment on pourrait faire ça en sql pur avec une seule requête, sans avoir des infos dupliqués dans les résultats.

À noter qu'il est prévu de transformer les résultats des daos et de jdb qui sont actuellement des tableaux de records, en itérateur (jDbRecordSet va implémenter Iterator). Ce qui sera beaucoup, beaucoup moins gourmand en mémoire, tout en gardant une utilisation aussi simple qu'un tableau (si vous n'utilisez que des foreachs avec les résultats actuels, ce sera totalement transparent)

 
Page
  1. DAORecords et optional foreign tables