Log:
gestion propre des liens de documents avec les articles etc ; resoud les bugs #1015 (vignettes affichees deux fois) et #1025 (vraiment supprimer un document)
une fonction dans inc/documents permet de lister les documents orphelins, une autre permet de les supprimer en base et physiquement dans IMG/ ; mais elles ne sont pas indispensables pour resoudre le probleme : c'est dans la boucle DOCUMENTS qu'on ajoute des jointures marrantes ; je laisse donc provisoirement en option, le temps qu'on en discute
ces jointures demontrent, a mon avis, qu'il n'est pas souhaitable de multiplier les tables spip_documents_(objets), et qu'il faudrait plutot en faire une seule avec un champ type d'objet
Log:
gestion propre des liens de documents avec les articles etc ; resoud les bugs #1015 (vignettes affichees deux fois) et #1025 (vraiment supprimer un document)
une fonction dans inc/documents permet de lister les documents orphelins, une autre permet de les supprimer en base et physiquement dans IMG/ ; mais elles ne sont pas indispensables pour resoudre le probleme : c'est dans la boucle DOCUMENTS qu'on ajoute des jointures marrantes ; je laisse donc provisoirement en option, le temps qu'on en discute
ces jointures demontrent, a mon avis, qu'il n'est pas souhaitable de multiplier les tables spip_documents_(objets), et qu'il faudrait plutot en faire une seule avec un champ type d'objet
surtout que les plugins peuvent ajouter leurs liens (cf f&t qui a une table spip_documents_donnees), donc il faut que le mecanisme soit extensible etc etc ...
Par contre cela veut dire qu'il faut choisir comment representer les objets en base sql :
soit un id, mais qui necessite de maintenir/gerer une table objet<=>id qui prenne en compte les ajouts des plugins. Ce sera necessairement une table sql car les id peuvent etre differents d'un spip a l'autre de ce fait, et la base doit assurer sa propre integrité ... bof pour moi
soit un varchar avec le type de l'objet, c'est plus couteux mais c'est en clair
soit un enum au cas par cas, ce qui permet au passage de savoir quels types sont possible pour une liaison donnee, et force les plugins à s'ajouter à la liste des enums (est ce une operation simple que cela, par contre ?). Mais je crois avoir compris que pour PG c'etait moins portable ...
Le 7 sept. 07 à 09:23, cedric.morin@yterium.com a écrit :
soit un id, mais qui necessite de maintenir/gerer une table objet<=>id
qui prenne en compte les ajouts des plugins. Ce sera necessairement une
table sql car les id peuvent etre differents d'un spip a l'autre de ce
fait, et la base doit assurer sa propre integrité ... bof pour moi
soit un varchar avec le type de l'objet, c'est plus couteux mais c'est
en clair
soit un enum au cas par cas, ce qui permet au passage de savoir quels
types sont possible pour une liaison donnee, et force les plugins à
s'ajouter à la liste des enums (est ce une operation simple que cela,
par contre ?). Mais je crois avoir compris que pour PG c'etait moins
portable ...
La couche d'abstraction transforme les ENUM en Varchar, ce n'est pas un problème en soi. En revanche, les index numériques sont réputés plus efficaces (et intuitivement ça parait évident) que les Varchar, donc s'il y a le choix il vaut mieux un type numérique.
La couche d'abstraction transforme les ENUM en Varchar, ce n'est pas
un problème en soi. En revanche, les index numériques sont réputés
plus efficaces (et intuitivement ça parait évident) que les Varchar,
donc s'il y a le choix il vaut mieux un type numérique.
C'est ce qu'on a aussi pour l'indexation : unifions : chaque table
doit avoir une clé numérique... pourquoi pas un hash du genre
crc32(connexion, nom_table) ?
La couche d'abstraction transforme les ENUM en Varchar, ce n'est pas
un problème en soi. En revanche, les index numériques sont réputés
plus efficaces (et intuitivement ça parait évident) que les Varchar,
donc s'il y a le choix il vaut mieux un type numérique.
C'est ce qu'on a aussi pour l'indexation : unifions : chaque table
doit avoir une clé numérique... pourquoi pas un hash du genre
crc32(connexion, nom_table) ?
Log:
gestion propre des liens de documents avec les articles etc ; resoud les bugs #1015 (vignettes affichees deux fois) et #1025 (vraiment supprimer un document)
une fonction dans inc/documents permet de lister les documents orphelins, une autre permet de les supprimer en base et physiquement dans IMG/ ; mais elles ne sont pas indispensables pour resoudre le probleme : c'est dans la boucle DOCUMENTS qu'on ajoute des jointures marrantes ; je laisse donc provisoirement en option, le temps qu'on en discute
ces jointures demontrent, a mon avis, qu'il n'est pas souhaitable de multiplier les tables spip_documents_(objets), et qu'il faudrait plutot en faire une seule avec un champ type d'objet
tu veux dire que tu veux gérer les documents comme on gère des mots-clés ? ajouter, retrancher, partager... lister à part etc.
Claude
surtout que les plugins peuvent ajouter leurs liens (cf f&t qui a une
table spip_documents_donnees), donc il faut que le mecanisme soit
extensible etc etc ...
Par contre cela veut dire qu'il faut choisir comment representer les
objets en base sql :
soit un id, mais qui necessite de maintenir/gerer une table objet<=>id
qui prenne en compte les ajouts des plugins. Ce sera necessairement une
table sql car les id peuvent etre differents d'un spip a l'autre de ce
fait, et la base doit assurer sa propre integrité ... bof pour moi
soit un varchar avec le type de l'objet, c'est plus couteux mais c'est
en clair
soit un enum au cas par cas, ce qui permet au passage de savoir quels
types sont possible pour une liaison donnee, et force les plugins à
s'ajouter à la liste des enums (est ce une operation simple que cela,
par contre ?). Mais je crois avoir compris que pour PG c'etait moins
portable ...