la table spip_documents_liens unifiee sur le modele (id_document,id_objet,objet)
ce qui la rend extensible et utilisable par les plugins pour tout type d'objet
Oui ; ce serait pas mal d'unifier, d'ailleurs. Je pense que (type, id)
est le meilleur choix, ou alors (type, id_objet). "objet" indique
plutôt un objet qu'un type d'objet
Je crois que le id_objet, type de spip_urls est similaire au id_objet,objet de spip_liens_documents
L'apport essentiel des derniers commit est que le compilo a été modifié pour être capable de faire
une jointure id_xx <-> (id_objet,objet=xx)
J'aurais pu utiliser le mot 'type', mais objet peut être un tout petit peu différent de type dans certain cas tordus :
objet correspond litteralement a xx de id_xx, il est construit comme cela pour des questions de performance.
Je crois qu'après la sortie de la 2.0, avec un peu de recul, et sous réserve de ne pas avoir de mauvaise surprise en terme de perfo, il sera bon d'unifier les nomenclatures :
- dans spip_urls, avec peu d'impact sauf pour ceux qui ont un fichier d'url personalisées
- dans spip_forum, pour permettre effectivement de generaliser les forum a tout type d'objet (encore faut il gérer cela au niveau du formulaire ...)
- dans spip_mots_xx -> spip_mots_liens
- peut-être aussi dans spip_auteurs_xx -> spip_auteurs_liens ?
Il est à noter que cette implémentation est un peu plus gourmande en stockage, puisque l'on stocke l'objet en chaine de texte, de façon repetee. Toutefois, je ne pense pas que ce soit encore critique de nos jours.
Il faut peut être faire un ticket 'prochaine version' sur ce sujet.
Pour le moment, on va déjà essayer de traquer complètement les bugs eventuels que l'on a introduit avec les modifs du compilateur.
* cedric.morin@yterium.com tapuscrivait, le 09/07/2008 10:15:
Il est à noter que cette implémentation est un peu plus gourmande en stockage, puisque l'on stocke l'objet en chaine de texte, de façon repetee. Toutefois, je ne pense pas que ce soit encore critique de nos jours.
Oui ; ce serait pas mal d'unifier, d'ailleurs. Je pense que (type, id)
est le meilleur choix, ou alors (type, id_objet). "objet" indique
plutôt un objet qu'un type d'objet
Il faut faire attention au critère {type=xx} qui cherche des groupes de mots. Ca risque d'être un problème.
* cedric.morin@yterium.com tapuscrivait, le 09/07/2008 10:15:
Il est à noter que cette implémentation est un peu plus gourmande en stockage, puisque l'on stocke l'objet en chaine de texte, de façon repetee. Toutefois, je ne pense pas que ce soit encore critique de nos jours.
voui, et prosaiquement, grep 'objet' sur le code de spip est plus cible que grep 'type'
pis là j'ai tout ecrit le compilo pour faire (id_objet,objet), on pourra pas s'amuser à changer ça tous les 4 matins...
Donc à présent dans spip_documents_liens il y a les colonnes
id_objet
objet
Dans spip_urls
type
id_objet
Est-ce similaire ?
Oui ; ce serait pas mal d'unifier, d'ailleurs. Je pense que (type, id)
est le meilleur choix, ou alors (type, id_objet). "objet" indique
plutôt un objet qu'un type d'objet
pourquoi ne pas avoir une table « objet » ( id, libelle ) contenant les différents objets de spip et éventuellement d’autre rajoutables par les plugins ?
et effectivement on aurait juste une jointure en plus plutot que d’avoir le champ enum ou en varchar, et puis ce serait plus extensible, non ?
