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 > [email protected] > http://ml.dotclear.org/listinfo/dev > _______________________________________________ Dev mailing list [email protected] http://ml.dotclear.org/listinfo/dev
