Ses derniers messages sur les forums
Come le dit la documentation
curl_init :
Returns a cURL handle on success, FALSE on errors.
Donc ce serait bien de tester le retour de curl_init pour détecter une éventuelle erreur.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Ça dépend de ta plate-forme. Quel est le système d'exploitation sur lequel fonctionnent tes développements ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
En complément de la question de La Globule, quel est le create de la table (parce que je vois bien le coup du stockage dans un timestamp ^^;) ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(diablo) L'utilité est fondamentale.
Premièrement, concaténer des chaîne est au mieux une obfuscation du code, au pire un trou de performance. En C++, l'opérateur d'injection et l'opérateur de concaténation ont aussi été pensés pour jeter aux gémonies les fonctions *printf. Mais le problème de performances, le manque de lisibilité et l'aspect pratique des formats fait que le standard comportera bientôt à nouveau cette fonctionnalité indispensable (actuellement il faut utiliser boost::format).
L'opérateur de concaténation alloue une nouvelle chaîne à chaque concaténation.
sprintf analyse la chaîne de format, analyse les paramètres qui lui sont fournis, alloue une chaîne, et écrit dedans.
L'autre avantage c'est qu'on peut aussi formater la chaîne. Ce peut être utile pour produire des fichiers CVS à champs fixe.
Sinon, pour la consultation de la documentation, je suis bien d'accord. Tout est exprimé en long et en travers dans la documentation, avec moults exemple. De plus, *printf est un standard en programmation, il faut le connaître.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Normalement, depuis PHP tu devrais démarrer la transaction, puis effectuer les requêtes les unes après les autres puis terminer avec un commit.
Si tu veux mettre toutes les requêtes dans une seule chaîne, il faut utiliser les fonctions multiquery. Les fonctions habituelles ne supportent pas les multiqueries.
Tu as des messages d'erreur quand tu exécutes les requêtes ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Trier sur l'identifiant unique (et non l'index) est quelque chose de mal. Premièrement parce qu'il n'a aucune signification pour tes données. C'est essentiellement une clé de convenance pour faire des liens entre les tables.
Il n'y a aucune garantie que la donnée suivante soit identifiée par id + 1.
L'offset de la clause limit ne correspond en aucun cas à id. L'offset utilisé est la position dans l'ensemble de résultats obtenus par ta clause select.
Tu as trois solutions qui s'offrent à toi.
1 - y aller à la bourrin (comme toute les applications PHP que j'ai pu voir)
3 - y aller un peu plus finement, en gérant un « pointeur » vers le précédent et le suivant selon l'ordre.
2 - y aller finement en utilisant les représentation intervalaires.
La première solution est assez triviale. tu fais une requête sur l'ensemble de tes annonces :
select id_annonce as id
from annonce
where id_categorie = %d
order by annonce.titre
À ce moment là, il te suffira de parcourir l'ensemble des résultats :
<?php
$dbcon = new mysqli(/* ... */) ;
$result = $dbcon->query(sprintf(SQL_SELECT_ANNONCE_BY_CATID
, (int) $donnee['id_categorie'])) ;
if(!$result)
die($dbcon->error) ;
$next = null ;
$current = null ;
$previous = null ;
while($current = $result->fetch_object())
{
if($current->id == $donnee['id_annonce'])
{
$next = $result->fetch_object() ;
break ;
}
$previous = $current ;
}
$result->close() ;
// À présent tu as la triade nécessaire pour faire tes liens
?>
Comme tu peux t'en douter, tu risque d'avoir des problèmes de
performance si tu as trop d'annonce. C'est pourquoi si cela s'avère
nécessaire, réfléchis à quelque chose de plus évolué.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(Keika) Non, le order est fait avant la clause limit. En conséquence, le tri se fait sur l'ensemble des tuples sélectionnés.
Ce que veut faire (Michael_Lee) n'est pas possible directement.
Au pire, et si on a pas peur de faire des trucs ignobles :
<?php
select * from
( select * from news
order by id asc
limit 5
) order by rand() ;
?>
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
C'est normal. Les bibliothèques de détection de type de fichier se base sur les premiers octets d'un fichier. Les bibliothèques de détection des types ne savent pas manipuler les types qu'elles tentent de détecter. La seule chose qu'elles font, c'est observer les premiers octets qui peuvent leur donner un indice sur ce qu'est le fichier.
En aucun cas ils ne peuvent détecter qu'un fichier ne contient pas des données valides pour le type de fichier. Dans le cas contraire, à chaque teste de fichier, il faudrait que l'utilitaire analyse et valide l'ensemble du fichier. Tu te doutes bien que c'est un puits de performances.
Ceci dit, je ne comprends pas pourquoi tu t'en-tête à chercher un moyen de contrôler le contenu des images. Surtout que je t'ai donné la solution, et que visiblement tu as oublié de la vérifier.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Il a tout du fichier GIF, puisqu'il en a la tête :p
Bon, finalement, quel est le problème ? En quoi ce fichier te perturbe ? (à noter que la fonction que je t'avais indiqué détecte que la chaîne ne correspond pas à une image).
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(La Globule) Ta regex pour les courriels elle pue :p
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
