cedric.morin@yterium.com a écrit :
Le 26 mai 09 à 13:31, Stephane a écrit :
Hello,
j'ai une vieille version de F&T mais je ne crois pas que ca ait été corrigé depuis.
Lorsque je fais un importation en remplacant les données, il faut que ma colonne s'appelle id_donnee pour que ca fasse effectivement un remplacement.
si ma colonne s'appelle id (ce qui est le cas lors de l'export), il me met à la poubelle les anciennes données et ajoute de nouvelles avec de nouveaux id
j'ai pas encore bien compris d'ou ca venait ($clé = .... ou plus bas $id_donnee = $ ligne[$cle] ), c'est pas bien mechant, mais il vaut mieux etre au courant.
ça me dit quelque chose, il me semble que je l'avais fait exprès, considérant que
- le but d'importer est en général d'importer du contenu, pas des id_donnee précises
- ce type d'opération était potentiellement reversible alors que le remplacement des données existantes par les données importées ne l'était pas
Une bonne interface qui laisse le choix entre les deux serait sans doute bien mieux !
oui ou peut etre une explication, car la, c'est un peu surprenant comme comportement :
avec le meme fichier, le meme mappage, selon que l'entete de mon fichier csv s'appelle id ou id_donnee (dans les 2 cas associés à id_donnee), dans un cas j'ai mise à la poubelle des ancien et ajout, dans l'autre remplacement
à partir du moment ou on associe id_donnee à une colonne du csv, pour moi, c'est qu'on veut effectivement du remplacement avec conservation des id
mais encore une fois, j'ai l'impression que c'est plutot un test qui est foireux et regarde un $tab['id_donnee'] au lieu $tab[$map['id_donnee']], je vois en gros ou ca doit etre, mais il faut que je passe un import en posant un peu de log pour comprendre exactement ou est ce test
mais comme c'est un truc en prod, je peux pas trop faire de tests, il faut d'abord que je me remonte un site test en local.
un autre jour...
en fait, il y a un autre truc génant : on ne peut pas importer/exporter les id_auteur associés aux données (ni url, mais la, c'est moins important)
du coup, si on fait export => traitement => import, on perd cette information.
Mais c'est bien sur discutable, puisque on peut vouloir que la donnée "appartienne" à l'auteur qui l'importe
oui, ce type d'usage n'a pas forcément été pris en compte.
je sais, et c'est moi qui ait mis le doigt dedans avec mes histoires de unique/modifiable
du coup, j'utilise ca pour gérer des profiles.
comme il y avait du nettoyage à faire, on a fait export / traitement dans OOcalc et au moment de réimporter.. on perd l'id_auteur et l'url d'origine
Pour moi, fonctionnellement, c'est pareil, il faudrait pouvoir associer url et id_auteur, si on les a et qu'on fait le mappage, c'et sans doute qu'on veut les conserver...
bon, ca, c'est plus chaud et c'est pas mon besoin, donc je regarderai + tard en 2.0.
j'ai aussi sous le coude l'affectation d'id_auteur à une donnée (selon une autorisation spécifique "attribuer_form_donnee") sur les formulaires, pas moyen de faire ca en plugin, j'ai charcuté une vieille version, mais les modifs sont pas trop lourde (avec un fonctionnel limité, on ne peut pas affecter à la création, juste modifier après si on est autorisé)
un interet pour la version de dev ?
hum, je sais pas trop. Pas vraiment d'idée sur ce sujet.
oui, comme je disais, c'est un peu specifique à l'usage de "modifiable"
mais ca reste limité à un propriétaire par fiche avec mon approche alors qu'on pourrait utiliser spip_auteurs_donnees.
On verra sur la v2, mais sur ma version, ca oblige à faire des modifs qu'on peut difficilement faire avec des pipeline.
je me le garde sous le coude alors...
@++
Cédric