J'ai commencé à tester des solutions pour ce ticket et en effet le
changement en char(16) (pour être large) est la meilleur solution et on
garde les status existant ça marche pas mal, après 2 fonctions de plus
pour enregistrer/gérer un nouveau type suffise et pour leur nom: premier
arrivé, premier servis. En tout logique en nom de status en liaison avec
le nom du plugin devrait suffire à ne par avoir de collision.
Pour les comment_status on verra arpès si on sort les commentaires du
core ;-)
Le 15/07/2012 10:42, Dsls a écrit :
Hello,
Chantier à envisager sur la branche sexy : le déverrouillage du post_status.
J'ai reparcouru les commentaires du ticket et le fil du forum.
Il y avait 2 solutions proposées: ajout d'une table (association
post_status <-> status texte), ou changement de type de colonne.
Après réflexion, je pense que le second scénario est le meilleur : on
passe la colonne post_status comme la colonne post_type, et on crée
l'index qui va bien dessus.
les post_status deviennent (entre parenthèses les valeurs actuelles) :
pending (-2), scheduled (-1), unpublished (0), published (1)
Pour les commentaires : junk (-2), pending (-1), unpublished(0), published (1).
A moins qu'on ne soit plus radical, qu'on impose un CHAR(4) comme type
de colonne, pour être moins gros en base, et un chouïa plus
performant...
--
Bruno
_______________________________________________
Dev mailing list
Dev(a)list.dotclear.org
http://ml.dotclear.org/listinfo/dev