|
|
Héritage et jointure de table (BD) |
|
Aspirant  
Inscrit: 15/01/2005 14:09
|
Bonjour à tous,
Voici une question qui me chauffe les neurones et pour laquelle je n'arrive pas à trouver une jolie solution.
Voici ce que je voudrai faire:
- J'ai une classe XOOPS A (avec son handler) à laquelle j'associe la table dbA
- J'ai une classe XOOPS B (avec son handler) qui hérite par extension de A
L'idée qui me plairait bien, ce serait d'associer une table dbB qui ne contienne que les éléments que l'on ajoute à B par rapport à A, ainsi qu'un identifiant permettant d'effectuer la jointure entre dbA et dbB.
Le hic est qu'en utilisant XoopsPersistableObjectHandler, on ne peut associer qu'une seule table pour que les choses soient automatisées.
Pour effectuer les choses correctement, il faut bricoler en se serveur de B comme wrapper à A et savoir quels champs vont dans dbA et dans dbB.
Bien entendu, ce problème se pose quelque soit la version de XOOPS.
Alors, quelqu'un a envi de se chauffer les neurones avec moi? :copain:
Pierre
Posté le : 19/12/2006 12:00
|
|
Don't worry, be happy
|
|
|
Re: Héritage et jointure de table (BD) |
|
Aspirant 
Inscrit: 18/12/2006 18:34
|
salut
et quel serait le but d'aller tout enregistrer en double?
++
Posté le : 19/12/2006 20:55
|
|
|
|
|
Re: Héritage et jointure de table (BD) |
|
Aspirant Inscrit: 15/01/2005 14:09
|
Et bien justement, l'intérêt serait de n'avoir que les données propres à chaque classe enregistrée dans les tables appropriées.
Du coup, aucune duplication...
Posté le : 19/12/2006 22:14
|
|
Don't worry, be happy
|
|
|
Re: Héritage et jointure de table (BD) |
|
Régulier  Inscrit: 06/01/2006 23:55
|
euh je vois pas ou est le probleme... J'utilise ce truc sur des objets et c'est effectivement un des interets de l'objet. Par exemple, quand tu attaques le insert de ton objet B, il suffit que la methode insert de B appel la methode insert de A et qu'elle fasse en plus les traitements specifiques a ton objet B (c-a-d ici l'insertion dans ta tableB)
class classA{
function insert(){
$sql = 'INSERT INTO tableA ....';
}
}
class classB extends classA{
function insert(){
parent::insert();
$sql = 'INSERT INTO tableB....';
}
}
le code peut etre bien sur conditionne ou autre
class classB extends classA{
function insert(){
if (...) parent::insert();
$sql = 'INSERT INTO tableB....';
}
}
Posté le : 21/12/2006 00:30
|
|
|
|
|
Re: Héritage et jointure de table (BD) |
|
Aspirant Inscrit: 15/01/2005 14:09
|
D'accord, ça c'est la méthode simple qui implique pleins de code au niveau du Handler, car il faudra surcharger les méthodes suivantes:
- function &get($id, $as_object = true)
- function &getObjects($criteria = null, $id_as_key = false, $as_object = true)
- function getList($criteria = null, $limit = 0, $start = 0)
- function getCount($criteria = null)
- function delete(&$obj, $force = false)
- function insert(&$obj, $force = false, $checkObject = true)
- function updateAll($fieldname, $fieldvalue, $criteria = null, $force = false)
- function deleteAll($criteria = null)
L'idée était quand de ne pas avoir à réécrire ces méthodes pour chacun des classes filles de A.
C'est parceque j'étais arrivé à cette même conclusion que je me suis dit que quelqu'un de malin... :banane:
Posté le : 21/12/2006 10:31
|
|
Don't worry, be happy
|
|
|
Re: Héritage et jointure de table (BD) |
|
Régulier Inscrit: 06/01/2006 23:55
|
Ben tout depend de ce que tu veux faire...
Tu n'as pas forcement besoin de les surcharger si tu n'as pas de comportement different.
Je suis dsl mais je comprends pas ton pb?
- Tu utilises un generateur de code pour creer tes classes? si oui ben effectivement il va te generer du code qui n'est pas utile dans ton cas, ben tu le supprimes...
- Si tu fait a la main (comme moi...) il n'y a aucun pb. Tu fais ce que tu veux comme tu veux, mais tu n'as aucune obligation d'ecrire des methodes dans ta classe fille si elles sont exactement identique a celle de la classe mere (en fait meme tu as pas du tout interet a le faire).
Tout depend au final de ce que tu fais comme modification dans ton extension de classes...
Mais typiquement d'apres ce que tu sembles vouloir faire c-a-d une classe A avec une tableA et une classe B qui rajoutes des colonnes dans une tableB
- function &get($id, $as_object = true)
Mais a priori si tu as rajoute des champs dans une 2nd table tu as interet a la reecrire celle-ci tout en appelant l'ancienne
- function &getObjects($criteria = null, $id_as_key = false, $as_object = true)
Pareil qu'au dessus
- function getList($criteria = null, $limit = 0, $start = 0)
Je me souviens plus de ce que ca fait mais bon a mon avis pareil qu'au dessus
- function getCount($criteria = null)
La si tu as creer une nouvelle table etc... tu as interet a ne faire le count que sur les donnees de ta table lie a ta classe donc a reecrire completement
- function delete(&$obj, $force = false)
Suppression a faire dans la tableB et aussi dans la tableA donc rappel de parent::delete
- function insert(&$obj, $force = false, $checkObject = true)
Insertion dans la table B et dans la table A rappel donc parent::insert
- function updateAll($fieldname, $fieldvalue, $criteria = null, $force = false)
Ca dependra des modif effectue si tu ne modifies que les colonnes de la table B pas besoin de jouer la methode du parent sinon updateAll dans la table A rappel donc parent::updateAll, a savoir qu'au final tu as juste besoin de savoir quels sont les champs de B.
- function deleteAll($criteria = null)
Tout dependra ici de comment tu as creer ta base, donc soit delete sur la table B et appel de parent:deleteAll soit tu as une cle etrangere dans ta base avec un delete cascade et tu fais le delete que sur un seul endroit (tout depend de ta conf MySQL)
Mais voila ca ca correspond au cas que je dirais standard ou tu rajoutes des champs dans une 2nd table. Mais apres tu as tout plein de possibilite en fonction de ce que tu veux faire fonctionnellement...
Moi dans un cas par exemple j'ai utilisé cette methode et j'ai redefinie que get, getObject, getCount et delete... tout le reste n'a pas ete redefinie, j'en avais absolument pas besoin.
Posté le : 21/12/2006 21:43
|
|
|
|
|
Re: Héritage et jointure de table (BD) |
|
Aspirant Inscrit: 15/01/2005 14:09
|
Je code avec mes petites mimines, pas de générateur. Donc, on fait ce que l'on veut.
Ton exxplication correspond à ce que j'ai fait. A un détail près, dans le handler de la classe A, il faut quand même surcharger les méthodes utiles, car la variable 'table' doit être initialiser avec le nom de la bonne table à modifier avec d'appeler parent::...
En fait, je cherchais une manière plus élégante de le réaliser...
Un grand merci pour ton aide en tout cas.
Posté le : 21/12/2006 22:40
|
|
Don't worry, be happy
|
|
|
Re: Héritage et jointure de table (BD) |
|
|
Guest_
|
et pourquoi ne pas créer un objet C qui ferait la jointure entre les deux ?
Posté le : 21/12/2006 23:16
|
|
|
|
|
Re: Héritage et jointure de table (BD) |
|
Aspirant Inscrit: 15/01/2005 14:09
|
Implicitement la jointure est réalisé par la classe B.
Le principe de la classe de jointure est a utiliser en cas de simulation d'héritages multiples. Mais il faut aussi surcharger toutes les méthodes utiles.
Dans mon cas, on ne fait que de l'héritage simple.
Posté le : 21/12/2006 23:32
|
|
Don't worry, be happy
|
|
|
Re: Héritage et jointure de table (BD) |
|
|
Guest_
|
Citation :
ppcm a écrit:
Implicitement la jointure est réalisé par la classe B.
C'est peut être là qu'il faut changer les choses. Avoir deux classes qui correspondent réellement aux tables (à leur structure physique) et avoir une troisième classe qui établit la relation entre les 2 (une façade en quelque sorte)
Posté le : 22/12/2006 08:30
|
|
|
Vous pouvez voir les sujets.
Vous ne pouvez pas débuter de nouveaux sujets.
Vous ne pouvez pas répondre aux contributions.
Vous ne pouvez pas éditer vos contributions.
Vous ne pouvez pas effacez vos contributions.
Vous ne pouvez pas ajouter de nouveaux sondages.
Vous ne pouvez pas voter en sondage.
Vous ne pouvez pas attacher des fichiers à vos contributions.
Vous ne pouvez pas poster sans approbation.
|
