Bonjour,

Je suis en train de mettre en place des DAO et je me demande si je passe pas à côté de qqchose. Admettons j'ai la structure suivante :

Table Utilisateur

• > numero
• > nom
• > prenom
• > sexe_fk

Table Sexe

• > numero
• > nom

Comment faire un DAO sur la table utilisateur qui fait un référencement direct sur la table Sexe sans devoir réécrire les propriétés de la table sexe dans la table utilisateur ? Autrement dit, dans l'exemple ci-dessous, comment est-ce que je peux accéder à la propriété nom de la table Sexe ?

<dao xmlns="http://jelix.org/ns/dao/1.0">
    <datasources>
        <primarytable name="utilisateur" realname="utilisateur" primarykey="numero" />
        <optionalforeigntable name="sexe" realname="sexe" primarykey="numero" onforeignkey="sexe_fk" />
    </datasources>
    <record>
        <property name="numero" fieldname="numero" datatype="int" autoincrement="true"/>
        <property name="nom" fieldname="nom" datatype="nvarchar" required="true"/>
        <property name="prenom" fieldname="nom" datatype="nvarchar" required="true"/>
    </record>
    <factory>
    </factory>
</dao>

Tout en sachant que j'ai également un DAO pour la table sexe :

<dao xmlns="http://jelix.org/ns/dao/1.0">
    <datasources>
        <primarytable name="sexe" realname="sexe" primarykey="numero" />
    </datasources>
    <record>
        <property name="numero" fieldname="numero" datatype="int" autoincrement="true"/>
        <property name="nom" fieldname="nom" datatype="nvarchar" required="true"/>
    </record>
    <factory>
    </factory>
</dao>

Car si il faut à chaque fois mettre toutes les propriétés dans chaque DAOs, ca me semble assez redondant et casse un peu le principe d'un DAO :/ Devrais-je donc utiliser jDb tout simplement ?

Je crois qu'il faut rajouter dans la balise <record> de ton DAO user :

<property table="sexe" name="nom" fieldname="nom" datatype="nvarchar" />

abys a dit :
Je crois qu'il faut rajouter dans la balise <record> de ton DAO user :

<property table="sexe" name="nom" fieldname="nom" datatype="nvarchar" />

.

Merci pour ta réponse :) Effectivement, c'est la solution officielle indiquée et qui fonctionne.

Pour une table de cette envergure ce n'est effectivement pas un très gros travail, mais quand on a une table qui contient plusieurs propriétés, qui à plusieurs tables étrangères et qui veut pouvoir accéder aux propriétés de ces dernières, c'est un travail long et pénible de devoir ré-écrire toutes ces propriétés. En plus d'être redondant avec des propriétés de DAO déjà existants finalement (si on les a créé).

Cela perd toute l'utilité de la "génération automatisée" des DAO et leur réutilisation.

Du coup pour le moment, j'utilise simplement jDb pour faire ce type de requêtes.. L'optimal serait que les DAO puissent "échanger" entre eux leurs propriétés, basés sur les clés étrangères. Une alternative serait que les DAO soient construits de sorte à ce qu'ils contiennent toutes les tables étrangères et leurs propriétés directement à la génération (et mis à jour lorsqu'on les recréés.

Maintenant, je me suis aussi demandé si c'est pas moi qui me méprends sur l'utilité des DAO. Sont-ils uniquement là à des fins de CRUD ? Si c'est le cas, il faut effectivement passé par jDb comme je le fais déjà.

Salut,

Je confirme qu'il n'y a que la solution de abys.

J'ai déjà pensé à une solution, d'indiquer un autre dao plutôt qu'une table, mais à l'implémentation, ça devient finalement plus complexe. Et surtout cela pose des problèmes de perf :

• pour que la classe PHP à générer soit à jour par rapport à ce qui est décrit dans les DAOS, il faut, non plus vérifier un fichier dao, mais plusieurs (et récursivement en plus !). Ou alors, pour éviter ce problème de perf, on pourrait faire en sorte que la classe ne soit générée que manuellement, lors d'une mise à jour de l'application par exemple. Enfin, bon, même en résolvant ce problème de check, il y a le souci de la complexité introduite par la récursivité.
• il arrive souvent que lorsqu'on veut joindre deux tables, on ne veuille pas tous les champs. Par exemple, pour lister des produits qui sont liés à une catégorie, on veut simplement le libellé de la catégorie, et pas forcément tous les autres champs qui sont dans la table catégorie. L'implémentation actuelle permet de sélectionner précisément les champs dont on a besoin dans les tables (et pas uniquement dans les tables annexes, mais aussi dans la table principale).

Rien n'empêche d'avoir plusieurs DAO qui utilisent les mêmes tables, mais avec des champs différents. Cela permet d'avoir des requêtes SQL optimisés pour tous les cas.

En fait, faudrait trouver une solution où on pourrait séparer la déclaration de tous les champs de chaque table, et la déclaration des différentes selections/jointures que l'on voudrait faire, de manière à ne pas répéter les caractéristiques de chaque champs.