jcaron

Surtout, du ne peut peut pas compter l'espace pris par des fichiers qui ont été effacés, mais qui sont encore ouverts. Par exemple, si tu as un fichier de logs, que tu le supprimes, mais que tu ne signales pas au processus qui écrit dedans de le fermer et d'en rouvrir un nouveau, le fichier continue à prendre de la place sur le disque, mais n'est pas visible dans l'arbo, et ne peut donc pas être pris en compte par du. Pire encore, le processus qui écrit dedans continue à le faire, donc le fichier continue à grossir! Jacques.

Et ce serait quoi l'intérêt? Le but de la ré-écriture c'est de transformer une URL "visible" en quelque chose d'autre en interne, mais l'erreur 500 implique déjà que tu affiches autre chose... J'ai loupé quelque chose? Jacques.

On commence par éliminer ceux qui croient que le langage SMS est de bon goût, font des fautes d'orthographe et ne savent pas utiliser la ponctuation à bon escient. Jacques.

Je n'ai pas regardé Weetix en détail, mais si je comprends bien, on peut participer (et éventuellement gagner) gratuitement. Donc il n'y a pas de participation financière obligatoire, donc ce n'est pas une loterie. Un lot à gagner tous les X codes saisis est considéré comme une loterie. Soit tu ne dis pas combien il reste de codes avant le prochain gagnant, est c'est donc 100% le hasard, soit tu dis combien il en reste, et quand on s'approche de 0 tout le monde joue en même temps et c'est le hasard qui détermine celui qui gagne. Le problème ne se situe pas au niveau du micro-paiement, mais à l'existence d'une loterie. Jacques.

Tel que tu le présentes, il s'agit en effet bel et bien d'une loterie. Comme rappelé dans l'autre sujet de discussion, il y a 4 critères pour que ce soit une loterie: - que ce soit ouvert au public (c'est le cas) - qu'il y ait intervention du hasard, même à titre accessoire (c'est le cas) - qu'il y ait participation financière, même indirecte (c'est le cas) - qu'il y ait quelque chose à gagner, même si ce n'est pas de l'argent (c'est le cas aussi). Sous cette forme, c'est donc une loterie, et c'est interdit. Comme expliqué là-bas, il te faut donc supprimer l'un des critères, les deux plus évidents étant de supprimer la participation financière (en permettant une participation gratuite ou un remboursant les frais de participation sur demande par exemple) ou le hasard (en transformant ça en vrai concours: écrivez le plus beau poème, faites le plus beau dessin, whatever...). Jacques.

Probablement quelque chose comme: DELETE FROM table WHERE (name,description,date) IN (SELECT name,description,min(date) FROM table GROUP BY 1,2 HAVING count(*)>1) Non? Evidemment, fais une copie de ta table d'abord, et fais un SELECT à la place du DELETE dans un premier temps pour vérifier que ça supprime bien ce que tu veux. Jacques.

Si tu peux découper le traitement en plusieurs morceaux, tu peux faire une partie du traitement, puis un redirect vers le même script avec un paramètre différent qui veut dire qu'il faut faire la deuxième partie, et ainsi de suite. Il te faudra probablement stocker des résultats intermédiaires quelque part. Ceci étant dit, un serveur web (mutualisé en plus) ne me paraît pas vraiment l'endroit idéal pour une tâche de ce genre... Jacques.

Addslashes gère le cas général, alors que mysql_real_escape_string gère les choses exactement comme il faut pour mysql. Il y a tout un tas de cas de figure qui ne passent pas avec addslashes. Jacques.

+1 sur le fait que pour utiliser un auto-increment, soit tu ne dois pas préciser du tout la colonne (et donc utiliser une liste de colonnes: INSERT INTO table (liste des colonnes) VALUES (liste des valeurs)), soit passer "default". Au delà, passer des variables par concaténation, c'est très dangereux, et sujet à de nombreuses erreurs. Il suffit qu'il y ait un ' dans un des champs, et plof, ça ne marche plus. Et ça peut être très nettement pire si les variables viennent directement ou indirectement de l'extérieur (cf injection SQL). Au minimum, utilise mysql_real_escape_string sur chacune des variables passées, au mieux utilise PDO. Jacques.

Tu as vérifié le HTML généré? Il contient bien tout ce qu'il faut comme il faut ou pas? Tu n'aurais pas un problème sur le format du "$i" (genre d'un côté ou de l'autre il est formaté sur 3 chiffres et pas un de plus)? Au passage, le $tab[$i] sans encodage, ça va faire des choses pas belles si tu as des " ou des & dans le contenu de ces variables (au moins). Jacques.

Si je comprends bien (difficile vu le peu de détails), tu as deux scripts: un premier qui lit un fichier et qui fait un POST de plein de variables vers un deuxième qui reçoit ces variables en POST et fait tout plein de choses avec, et dans certains cas ce deuxième script ne reçoit pas tout ce qu'il devrait. C'est ça? Ou alors tu as un premier script qui génère une page HTML avec un formulaire avec tout plein de variables et un POST vers le deuxième script? La première chose à déterminer, c'est de quel côté se situe le problème: est-ce-que c'est le premier script qui n'envoie pas tout, ou est-ce que c'est le deuxième qui ne reçoit pas tout? S'il y a beaucoup de varialbles, je suppose aussi qu'elles sont numérotées d'une façon ou d'une autre, peut-être que tu n'as pas la même convention de part et d'autre? Commence par examiner ce qu'envoie le premier script pour t'assurer qu'il envoie bien tout comme il faudrait. Une fois que c'est fait, tu pourras te concentrer sur le deuxième script. Jacques.

Une méthode qui permet quand tout va bien de réduire les temps d'accès, c'est de séparer une table avec des champs importants en deux. Par exemple, pour tes annonces, tu fais une première table avec les colonnes qui correspondent aux critères de filtrage et de tri (département, prix, type, date, etc.), et une deuxième table avec les colonnes qui ne sont pas utilisées pour le filtrage ou le tri et qui peuvent être plus longues (titre, description, etc.). Comme ça, si le planner SQL fait bien son travail, il n'a besoin d'accéder qu'à la première table (qui est beaucoup plus petite et donc a plus de chances de rester en cache) pour déterminer les lignes à retourner, et ensuite seulement il va piocher les quelques lignes dont il a besoin dans l'autre table. Mais quoi qu'il arrive, si tu as plus de données que de RAM, il y a un moment où des bouts de table ne vont pas être en RAM, et il va falloir aller les chercher sur le disque, ce qui est forcément plus lent. Jacques.

Ton formulaire pointe sur le script, mais le script fait une redirection dans certains cas de figure. Sans savoir ce qu'est ton script et ce qu'il contient difficile de t'en dire plus, mais c'est sûr, il fait une redirection. Note que c'est une stratégie courante pour un script qui gère un POST que de faire un redirect après le POST. Par exemple sur un forum, le script qui va traiter le formulaire de soumission de message va généralement faire un redirect vers la liste des messages. De la même façon, un script d'authentification va souvent afficher un résultat si l'authentification échoue, mais faire un redirect vers une autre page si l'authentification réussit. Dans la plupart des cas, les crawlers ne font pas de POST (Google a commencé à en faire dans des cas très limités où ils sont relativement sûrs que ça ne va pas avoir d'effet). Contrairement à un GET qui ne doit pas avoir d'effet (un GET doit être "idempotent"), un POST a souvent un effet (créer un message, faire une commande...). De surcroît, le moteur va avoir du mal à deviner ce qu'il doit mettre dans le POST s'il y a des champs texte. Donc non, ça ne devrait avoir aucune influence sur ton référencement (sauf si tu utilises un POST à un endroit qui n'est pas opportun). Jacques.

Tu as une redirection quelque part dans ton script. Cherche bien, tu vas la trouver :-) Jacques.

Les XPS ce sont les machines avec des processeurs/cartes graphiques puissantes, à la base pour les gamers et autres gens exigeants. L'expérience que j'en ai eu sur des portables XPS plus anciens, c'est que côté silence c'est pas vraiment ça. Je ne sais pas ce que ça donne sur les PC de bureau. Moi, perso, après des années avec Dell, je viens de repasser au Mac (le MacBook Pro Retina 15 pouces est cher, mais c'est une vraie merveille). Avec Parallels Desktop je peux continuer à utiliser les apps Windows dont je peux avoir besoin (une seule en fait). Tu peux jeter un oeil sur les Mac mini à titre de comparaison. Jacques.

Effectivement là ça risque d'être difficile de faire des index pour toutes les combinaisons de critères. Ceci dit, suivant la proportion de lectures et d'écritures, ça peut être tout à fait "rentable". Sinon tu peux essayer de faire des stats sur les combinaisons les plus courantes, et mettre les index correspondants pour voir ce que ça donne. Jacques.

Je ne sais pas d'où tu sors cette regexp, mais si le but c'est de vérifier qu'une adresse e-mail est valide, elle est complètement fausse (en plus d'être complètement illisible). Jacques.

C'est mieux, mais c'est loin d'être optimal, surtout qu'il utilise toujours un filesort. Idéalement, avec les bons index, il ne devrait avoir besoin que de charger les N premières lignes nécessaires, et ne pas faire de filesort. Tu as combien de critères optionnels et combien de critères de tri possibles? Jacques.

Le planner de mysql est probablement nettement plus simpliste que celui de postgresql, mais j'espère quand même que sur un cas aussi facile il retombe sur ses pattes :-) D'ailleurs le plan choisi montre que c'est le cas, c'est juste que les index ne sont pas suffisants pour arriver à un bon résultat. Jacques.

Si je décode correctement les choses, tu as des index sur chaque colonne, plutôt qu'un (ou plusieurs) index sur plusieurs colonnes? Si c'est bien le cas, suivant la répartition des données dans la table, c'est pas du tout évident qu'aucun index n'aide tant que ça, et en plus ça complique le boulot de mysql pour trouver quel index il va utiliser. Dans ton exemple, il se pose donc la question de quel index il va utiliser: celui sur type, celui sur prix, celui sur demande, etc. Il finit par choisir celui sur cpdep (probablement parce qu'au vu des infos qu'il a, c'est le plus "discriminant"). Ça lui donne 6976 lignes, qu'il faut qu'il lise toutes, ensuite il trie tout ça (en utilisant un fichier temporaire), puis il fait le LIMIT, puis pour chacune de ces lignes, il faut qu'il fasse la jointure avec l'autre table. Ça représente une tonne d'I/O. Ta requête va vite quand les parties utiles de la table sont entièrement dans le cache de l'OS et que les E/S de ton disque ne sont pas saturées, mais il suffit de peu pour que ça soit éjecté du cache (ou que ce soit une requête sur une partie moins utilisée et donc pas en cache), et hop, il faut qu'il recharge tout ça depuis le disque, ce qui prend nettement plus de temps. Il peut aussi arriver qu'en fonction des valeurs des critères, il décide d'utiliser un autre index qui se révèle être moins discriminant, et l'oblige à charger encore plus de données. Plusieurs solutions: - la première, c'est au minimum d'ajouter les critères de tri dans chaque index susceptible d'être utilisé (ici ça donnerait un index sur cpdep,prix). Comme ça, il lit les lignes directement dans le bon ordre, et il peut s'arrêter dès qu'il en a assez (en tous cas postgresql le ferait, je suppose que mysql aussi) - la deuxième, c'est d'avoir un ou plusieurs index qui incluent plusieurs des colonnes qui sont utilisées comme critère. Si par exemple tu as forcément tous ces critères dans ton WHERE, un index sur cpdep,type,demande,loc,visible,prix serait idéal. Si c'est plus souple que ça il va falloir adapter un peu. L'ordre des colonnes dans l'index peut avoir pas mal d'importance aussi, suivant le niveau de "discrimination" de chaque critère. _AT_Dadou: Heureusement, un serveur SQL décent utilise généralement le même plan pour une jointure explicite (a JOIN b ON a.c=b.d) et une jointure implicite (a,b WHERE a.c=b.d) tant qu'il n'y a pas de OUTER JOIN dans les parages. D'ailleurs ça se voit bien dans le plan choisi: il utilise un index sur la première table pour limiter le produit cartésien à faire, donc il utilise le critère avant le produit cartésien, pas après. Au final, sauf cas particuliers, c'est plus une question de lisibilité qu'autre chose. Ça permet aussi de ne pas oublier un critère de jointure, et ça permet de permuter entre un INNER et un OUTER JOIN plus facilement (et aussi de mélanger les différents types de JOINs dans la même requête, parce que dans ce cas, un critère dans le WHERE et un dans le ON ne veulent pas du tout dire la même chose). Jacques.

La fonction peut être définie dans n'importe quel fichier, tant que celui-ci est bien inclus tu peux l'appeler, les fonctions php sont globales. Seules les méthodes d'une classe peuvent être privées. Quelques autres possibilités: - tu n'inclus pas le bon fichier (faute de frappe...) - tu n'inclus pas le bon fichier (chemin?) - tu as une faute de frappe dans le nom de la fonction Tu peux tester tout ça en copiant la fonction appelante dans le même source que la fonction appelée, vérifier si ça marche ou pas, puis dans le source "principal" (celui qui inclut les autres), et ainsi de suite. Jacques.

Tu es sûr que la fonction que tu appelles n'est pas définie à l'intérieur d'une classe (i.e. c'est une méthode)? Autre possibilité, une faute de frappe sur le nom de la fonction peut-être? Jacques.

J'avais repris le LIMIT 1,0 que tu avais donné (je n'utilise pas mysql mais postgresql qui a une syntaxe différente: OFFSET 1), mais ce n'est pas la bonne méthode pour sauter la première ligne (ça revient à dire "0 lignes après la première"). Il faut utiliser un LIMIT 1,beaucoup, par exemple LIMIT 1,1000000000. Jacques.

Logiquement, ça veut dire qu'il n'y a aucune ligne renvoyée par la sous-requête. Si tu ne tapes que la sous-requête, ça donne quoi? Jacques.

Le canvas, tu veux dire? Le Calva, ça se boit :-) Jacques.