Author: esj@rezo.net
Date: 2008-07-19 09:33:26 +0200 (sam, 19 jui 2008)
New Revision: 12098
Log:
Eviter sql_count
Modified:
spip/ecrire/action/editer_auteurs.php
spip/ecrire/exec/iconifier.php
spip/ecrire/inc/commencer_page.php
spip/ecrire/inc/referenceurs.php
Le 19 juil. 08 à 09:48, Matthieu Marcillaud a écrit :
esj@rezo.net a écrit :
Author: esj@rezo.net
Date: 2008-07-19 09:33:26 +0200 (sam, 19 jui 2008)
New Revision: 12098
Log:
Eviter sql_countPuis-je savoir le fond de ta pensée ? quel est l'objectif de les éviter ?
Raison officielle: ils coutent cher.
Mails il y a un raison officieuse sur laquelle ça reste entre nous pour le moment, car je n'en fais pas une condition à la sortie de la 2.0 il ne faut pas faire de fausse annonce. J'ai voulu regarder si l'interface SPIP-SQL était adapté à Oracle, plus précisément à l'interface OCI. Dans cette interface, l'équivalent de mysql_numrows, pg_numrows etc n'existe pas, si on veut cette info il faut rejouer la requête avec un count(*). Donc j'élimine tous les appels ou sql_count est en fait seulement un test de nullité, car ça revient à !sql_fetch. Je ne sais pas encore s'il y aura d'autres pbs avec Oracle, je n'irai peut-être pas jusqu'au bout, mais comme en plus, effectivement, ces appels ne sont pas gratuits dans les autres serveurs, autant les éliminer.
Emmanuel
hum
la on est tous très sages en se retenant de commit quoi que ce soit hors de la correction de bug, il ne faudrait pas que ce travail de réécriture, très justifiable sur le fond, nous réintroduise des bugs, et n'encourage qui l'un, qui l'autre, à rajouter son petit truc qu'il avait sous le coude mais qu'il se retenait de commit pour le moment... J'ai peur que cela nous ramène à diverger comme il y a un an, et ce serait là vraiment préjudiciable.
Est-ce que l'on ne pourrait pas attendre la sortie de la beta pour ces commits, et à ce moment, on fait une branche afin que la beta ne soit plus l'objet que de correctifs.
Plus on pourra attendre pour brancher, mieux cela vaudra pour eviter double correctifs, et si l'on pouvait vraiment s'en tenir aux tickets, cela serait vraiment bien.
Il reste encore, pour sortir une beta :
- un bug majeur sur l'upload de doc dans IE6, mais je crois que Renato est dessus,
- divers petits bugs de configuration sur les forums (au passage, les forums sont impliqués dans près de 20% des tickets, ce qui montre qu'on a là un point critique en terme de maintenance)
- les _L() restant à passer en chaine de langue
Cédric
Le 19 juil. 08 à 10:21, Committo,Ergo:sum a écrit :
Le 19 juil. 08 à 09:48, Matthieu Marcillaud a écrit :
esj@rezo.net a écrit :
Author: esj@rezo.net
Date: 2008-07-19 09:33:26 +0200 (sam, 19 jui 2008)
New Revision: 12098
Log:
Eviter sql_countPuis-je savoir le fond de ta pensée ? quel est l'objectif de les éviter ?
Raison officielle: ils coutent cher.
Mails il y a un raison officieuse sur laquelle ça reste entre nous pour le moment, car je n'en fais pas une condition à la sortie de la 2.0 il ne faut pas faire de fausse annonce. J'ai voulu regarder si l'interface SPIP-SQL était adapté à Oracle, plus précisément à l'interface OCI. Dans cette interface, l'équivalent de mysql_numrows, pg_numrows etc n'existe pas, si on veut cette info il faut rejouer la requête avec un count(*). Donc j'élimine tous les appels ou sql_count est en fait seulement un test de nullité, car ça revient à !sql_fetch. Je ne sais pas encore s'il y aura d'autres pbs avec Oracle, je n'irai peut-être pas jusqu'au bout, mais comme en plus, effectivement, ces appels ne sont pas gratuits dans les autres serveurs, autant les éliminer.
Emmanuel
_______________________________________________
spip-team@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-team
Le 19 juil. 08 à 12:25, cedric.morin@yterium.com a écrit :
hum
la on est tous très sages en se retenant de commit quoi que ce soit hors de la correction de bug, il ne faudrait pas que ce travail de réécriture, très justifiable sur le fond, nous réintroduise des bugs, et n'encourage qui l'un, qui l'autre, à rajouter son petit truc qu'il avait sous le coude mais qu'il se retenait de commit pour le moment... J'ai peur que cela nous ramène à diverger comme il y a un an, et ce serait là vraiment préjudiciable.
Dans la mesure où ce point précis est aussi une amélioration de performances, pb qui nous est suffisamment reproché, et surtout que la disparition potentielle de ce point de l'API SQL est en jeu, je pense que ça vaut la peine de le faire. Mais j'ai bien dit que je ne faisais pas de l'opérationnalité de SPIP-Oracle une condition à la sortie de la 2.0. J'ai de toutes façons beaucoup de choses hors SPIP à faire, si je tombe sur un pb vraiment gros, je laisse tomber au moins provisoirement. Mais les ressemblances entre PG et Orace sont suffisamment fortes pour que ça vaille la peine de regarder.
Emmanuel
Le 19 juil. 08 à 12:25, cedric.morin@yterium.com a écrit :
esj@rezo.net a écrit :
Author: esj@rezo.net
Date: 2008-07-19 09:33:26 +0200 (sam, 19 jui 2008)
New Revision: 12098
Log:
Eviter sql_count
Au fait, tu peux expliquer ce serveur nommé "-1" introduit ici:
http://trac.rezo.net/trac/spip/changeset/11400
et me confirmer que le sql_count(..., -1) introduit ici:
http://trac.rezo.net/trac/spip/changeset/11402
revient bien dans ce cas à sql_fetch puisqu'on ne teste que l'existence semble-t-il.
Emmanuel
L'import d'un dump d'une ancienne version de Spip est réalisé en 2 étapes :
- on créé les tables avec la structure de l'ancienne version, et un prefixe temporaire. Ces tables sont adressées par le serveur -1
- on importe tout le dump dans le serveur -1
- on upgrade les tables du serveur -1
- on recopie tout dans le serveur 0
J'ai utilisé -1 comme nom de serveur pour ne pas risque de retomber sur un nom de serveur utilisé par un fichier connect.
Le sql_count de 11402 sert juste à eviter de rentrer dans la boucle et de faire des ecrire_meta inutiles.
Cédric
Le 19 juil. 08 à 12:57, Committo,Ergo:sum a écrit :
Le 19 juil. 08 à 12:25, cedric.morin@yterium.com a écrit :
esj@rezo.net a écrit :
Author: esj@rezo.net
Date: 2008-07-19 09:33:26 +0200 (sam, 19 jui 2008)
New Revision: 12098
Log:
Eviter sql_countAu fait, tu peux expliquer ce serveur nommé "-1" introduit ici:
http://trac.rezo.net/trac/spip/changeset/11400
et me confirmer que le sql_count(..., -1) introduit ici:
http://trac.rezo.net/trac/spip/changeset/11402
revient bien dans ce cas à sql_fetch puisqu'on ne teste que l'existence semble-t-il.Emmanuel