--- Antoine Pitrou <pitrou@free.fr> a écrit :
Sinon, après quelques essais les risques de timeout
sur l'importation totale de la base semblent se
confirmer fortement. Du coup il va falloir faire ça
en plusieurs fois. Une idée serait de stocker l'état
courant de la restauration (en gros la position dans
le fichier XML) dans une table, et de traiter ce qu'on
peut traiter (jusqu'au timeout) à chaque passage dans
ecrire/index.php3. D'autres idées ?
Avoir un parametre indiquant combien d'enregistrements maxi on peut stocker
dans un fichier d'export. Des que tu depasses, tu crees un deuxieme fichier,
etc, etc. Tu importes les fichiers un par un apres.
Nico
Salut,
Avoir un parametre indiquant combien d'enregistrements maxi on peut stocker
dans un fichier d'export. Des que tu depasses, tu crees un deuxieme fichier,
etc, etc. Tu importes les fichiers un par un apres.
Si l'estimation du nombre d'objets par fichier
est fausse ou que le serveur est devenu plus
chargé ou qu'on doit transférer l'archive sur
un autre serveur notablement moins véloce, et
que du coup l'archive s'avère être inutilisable...
bofff...
Sinon, est-ce qu'il y en d'autres qui ont un avis
sur la chose (c'est pas que j'aime exhorter mais bon) ?
a+
Antoine.
Antoine Pitrou wrote:
Sinon, est-ce qu'il y en d'autres qui ont un avis
sur la chose (c'est pas que j'aime exhorter mais bon) ?
Ya peut être une astuce possible en utilisant une
"registered function". Cette fonction est apellée lorsqu'il
y a un time out. (voir features.connection-handling.html
dans le manuel php)
Si tu fais faire à la "registered function" un appel
du script même en train de s'exécuter (avec un "fopen")
en passant en paramêtre l'endroit où le script s'est
arreté, il y a peut être moyen de tricher sur le time
out (il faudra sans doute apeller la fonction
ignore_user_abort() dans le script).
Voilà une piste... (j'aurais volontiers filer un coup de
main si j'avais plus de temps...)
Michael
Deux trois bugs corrigés 
Plutôt des détails,
des machins liés aux forums (à propos, l'import
export fait les forums aussi maintenant), et
puis un beaucoup plus vicieux :
J'ai découvert, je ne sais pas si vous saviez
déjà, que le traitement des caractères
d'échappement (backslash \) par mysql n'est
pas le même selon la requête. En gros, si
on rentre \"toto\" dans la base avec UPDATE,
une lecture ressort \"toto\". Mais si on
rentre \"toto\" avec REPLACE, une lecture
ressort... "toto". Sans les slashes. Du coup,
l'importation (qui utilise REPLACE) avait un
comportement pervers : le premier cycle
export/import ne semblait pas provoquer de
dégâts, mais le deuxième cycle, alors que
rien n'avait changé en apparence (!), effaçait
un certain nombre de documents (les requêtes
de restauration n'étaient plus valides, à
cause des guillemets non antislashés)... burp !
Antoine Pitrou wrote:
J'ai découvert, je ne sais pas si vous saviez
déjà, que le traitement des caractères
d'échappement (backslash \) par mysql n'est
pas le même selon la requête. En gros, si
on rentre \"toto\" dans la base avec UPDATE,
une lecture ressort \"toto\". Mais si on
rentre \"toto\" avec REPLACE, une lecture
ressort... "toto". Sans les slashes. Du coup,
l'importation (qui utilise REPLACE) avait un
comportement pervers : le premier cycle
export/import ne semblait pas provoquer de
dégâts, mais le deuxième cycle, alors que
rien n'avait changé en apparence (!), effaçait
un certain nombre de documents (les requêtes
de restauration n'étaient plus valides, à
cause des guillemets non antislashés)... burp !
Curieux comme comportement. Même anormal.
Peut être est-ce lié à la configuration de php, et
la configuration des "magic quotes":
configuration.html#ini.magic-quotes-runtime
dans le manuel php. (utiliser phpinfo() pour connaitre
la configuration du serveur).
Cordialement,
Michael
Salut,
J'ai uploadé un nouveau snapshot dans "alpha"....
hem hem... (raclement de gorge)
http://www.minirezo.net/imprimer.php3?id_article=464
sinon........... du feedback ?