peut on faire des recherche critere dans un fichier en php
26 réponses
dav
au lieu de gérer une base MySql j'envisage pour un petit annuaire de
gérer mes données dans un fichier texte.
je vais donc utiliser fopen() et fputs. mais est il possible
d'envisager, par le biais de données récupérées dans un formulaire, de
faire une recherche avec des criteres, comme en sql, sur ce fichier
texte de façon a afficher dans un tableau les données trouvées ?
mon idée est d'afficher les résultats trouvés sous forme de liens, et
quand l'utilisateur cliquera dessus, de refaire une seconde recherche
dans le fichier de façon à n'afficher en fin de compte que
l'enregistrement voulu. (nom + prénom + service + numémro_tél)
En ce qui me concerne, Apache gère correctement l'accès (de manière atomique) aux fichiers textes. Je n'ai pas stréssé ces systèmes, mais je ne pense pas qu'il y ait de gros problèmes pour l'application envisagée.
j'ai bien du mal a croire a une telle chose. La seule facon de se premunir contre les effets de la concurence est d'utiliser des verrous sur les fichiers. Ce n'est pas pour rien si cela (les primitives de lock sur les fichiers) existent en php et aussi tous les autres langages pour les systèmes d'exploitation multi-utilisateurs ou multi-tache.
d'autre part, dans un contexte de concurence, le seek et les n° de ligne ne pourront jamais fonctionner. Il suffit d'imaginer 2 utilisateurs qui croisent les intéractions qu'ils ont avec le fichier, l'un en edition, l'autre en suppression pour voir qu'on va rapidement au clash.
Dans un contexte mono-utilisateur, je pense qu'il n'y aura pas trop de soucis, sauf a utiliser des onglets comme dans mozilla.
Demosthene wrote:
En ce qui me concerne, Apache gère correctement l'accès (de manière
atomique) aux fichiers textes. Je n'ai pas stréssé ces systèmes, mais je
ne pense pas qu'il y ait de gros problèmes pour l'application envisagée.
j'ai bien du mal a croire a une telle chose. La seule facon
de se premunir contre les effets de la concurence est d'utiliser
des verrous sur les fichiers. Ce n'est pas pour rien si cela
(les primitives de lock sur les fichiers) existent en php
et aussi tous les autres langages pour les systèmes d'exploitation
multi-utilisateurs ou multi-tache.
d'autre part, dans un contexte de concurence, le seek et les
n° de ligne ne pourront jamais fonctionner. Il suffit d'imaginer
2 utilisateurs qui croisent les intéractions qu'ils ont avec
le fichier, l'un en edition, l'autre en suppression pour voir
qu'on va rapidement au clash.
Dans un contexte mono-utilisateur, je pense qu'il n'y aura pas
trop de soucis, sauf a utiliser des onglets comme dans mozilla.
En ce qui me concerne, Apache gère correctement l'accès (de manière atomique) aux fichiers textes. Je n'ai pas stréssé ces systèmes, mais je ne pense pas qu'il y ait de gros problèmes pour l'application envisagée.
j'ai bien du mal a croire a une telle chose. La seule facon de se premunir contre les effets de la concurence est d'utiliser des verrous sur les fichiers. Ce n'est pas pour rien si cela (les primitives de lock sur les fichiers) existent en php et aussi tous les autres langages pour les systèmes d'exploitation multi-utilisateurs ou multi-tache.
d'autre part, dans un contexte de concurence, le seek et les n° de ligne ne pourront jamais fonctionner. Il suffit d'imaginer 2 utilisateurs qui croisent les intéractions qu'ils ont avec le fichier, l'un en edition, l'autre en suppression pour voir qu'on va rapidement au clash.
Dans un contexte mono-utilisateur, je pense qu'il n'y aura pas trop de soucis, sauf a utiliser des onglets comme dans mozilla.
Demosthene
j'ai bien du mal a croire a une telle chose. La seule facon de se premunir contre les effets de la concurence est d'utiliser des verrous sur les fichiers. Ce n'est pas pour rien si cela (les primitives de lock sur les fichiers) existent en php et aussi tous les autres langages pour les systèmes d'exploitation multi-utilisateurs ou multi-tache.
Je parlais d'opération atomiques sur le fichiers : Apache n'ouvrira pas plusieures fois le même fichier en ecriture. Je suis d'accord avec vous que la cohérence des informations en écritures passe par des locks.
C'est une solution qui s'alourdie de plus en plus, ce qui conforte mon idée d'envisager l'utilisation d'une base de donnée.
Pour information, le projet templeet, donne le choix entre fichiers et bases, peut-être y-a t-il à creuser de ce côté.
Démosthène
j'ai bien du mal a croire a une telle chose. La seule facon
de se premunir contre les effets de la concurence est d'utiliser
des verrous sur les fichiers. Ce n'est pas pour rien si cela
(les primitives de lock sur les fichiers) existent en php
et aussi tous les autres langages pour les systèmes d'exploitation
multi-utilisateurs ou multi-tache.
Je parlais d'opération atomiques sur le fichiers : Apache n'ouvrira pas
plusieures fois le même fichier en ecriture. Je suis d'accord avec vous
que la cohérence des informations en écritures passe par des locks.
C'est une solution qui s'alourdie de plus en plus, ce qui conforte mon
idée d'envisager l'utilisation d'une base de donnée.
Pour information, le projet templeet, donne le choix entre fichiers et
bases, peut-être y-a t-il à creuser de ce côté.
j'ai bien du mal a croire a une telle chose. La seule facon de se premunir contre les effets de la concurence est d'utiliser des verrous sur les fichiers. Ce n'est pas pour rien si cela (les primitives de lock sur les fichiers) existent en php et aussi tous les autres langages pour les systèmes d'exploitation multi-utilisateurs ou multi-tache.
Je parlais d'opération atomiques sur le fichiers : Apache n'ouvrira pas plusieures fois le même fichier en ecriture. Je suis d'accord avec vous que la cohérence des informations en écritures passe par des locks.
C'est une solution qui s'alourdie de plus en plus, ce qui conforte mon idée d'envisager l'utilisation d'une base de donnée.
Pour information, le projet templeet, donne le choix entre fichiers et bases, peut-être y-a t-il à creuser de ce côté.
Démosthène
Marc
Je parlais d'opération atomiques sur le fichiers : Apache n'ouvrira pas plusieures fois le même fichier en ecriture.
nous sommes dans un groupe php, et meme s'il est motorisé par le serveur Web apache, il n'en reste pas moins que c'est php qui ouvre et ferme les fichiers. Et la il n'y a aucun doute, php ouvre sans broncher plusieurs fois le meme fichier en ecriture.
maitenant je ne crois pas que apache puisse ouvrir un fichier en ecriture (sauf pour les logs) ; je ne cromprend pas vraiment le contexte dans ce cas precis.
Je parlais d'opération atomiques sur le fichiers : Apache n'ouvrira pas
plusieures fois le même fichier en ecriture.
nous sommes dans un groupe php, et meme s'il est motorisé par le serveur
Web apache, il n'en reste pas moins que c'est php qui ouvre et ferme
les fichiers. Et la il n'y a aucun doute, php ouvre sans broncher
plusieurs fois le meme fichier en ecriture.
maitenant je ne crois pas que apache puisse ouvrir un fichier
en ecriture (sauf pour les logs) ; je ne cromprend pas vraiment
le contexte dans ce cas precis.
Je parlais d'opération atomiques sur le fichiers : Apache n'ouvrira pas plusieures fois le même fichier en ecriture.
nous sommes dans un groupe php, et meme s'il est motorisé par le serveur Web apache, il n'en reste pas moins que c'est php qui ouvre et ferme les fichiers. Et la il n'y a aucun doute, php ouvre sans broncher plusieurs fois le meme fichier en ecriture.
maitenant je ne crois pas que apache puisse ouvrir un fichier en ecriture (sauf pour les logs) ; je ne cromprend pas vraiment le contexte dans ce cas precis.
bibi.skuk
j'oublie encore qu'il y a plusieurs utilisateurs...
Effectivement, ca ne marchera pas...
ou plutot si, mais le resultat risque d'etre fort decevant...
donc on disait ?? txtSQL/SQLlite ?
j'oublie encore qu'il y a plusieurs utilisateurs...
Effectivement, ca ne marchera pas...
ou plutot si, mais le resultat risque d'etre fort decevant...
j'oublie encore qu'il y a plusieurs utilisateurs...
Effectivement, ca ne marchera pas...
ou plutot si, mais le resultat risque d'etre fort decevant...
donc on disait ?? txtSQL/SQLlite ?
Demosthene
nous sommes dans un groupe php, et meme s'il est motorisé par le serveur Web apache, il n'en reste pas moins que c'est php qui ouvre et ferme les fichiers. Et la il n'y a aucun doute, php ouvre sans broncher plusieurs fois le meme fichier en ecriture.
Donc j'aurais confondu, j'avais fait des écritures "atomiques" en php une inclusion de chaine assez longue et j'en ai conclu un peu vite que c'était apache.
Je vais refaire des tests intensifs avec trois clients et des "timeout" en javascript pour voir s'il y a des confusions.
Je ferais un retour sur cette liste
Démosthène
nous sommes dans un groupe php, et meme s'il est motorisé par le serveur
Web apache, il n'en reste pas moins que c'est php qui ouvre et ferme
les fichiers. Et la il n'y a aucun doute, php ouvre sans broncher
plusieurs fois le meme fichier en ecriture.
Donc j'aurais confondu, j'avais fait des écritures "atomiques" en php
une inclusion de chaine assez longue et j'en ai conclu un peu vite que
c'était apache.
Je vais refaire des tests intensifs avec trois clients et des "timeout"
en javascript pour voir s'il y a des confusions.
nous sommes dans un groupe php, et meme s'il est motorisé par le serveur Web apache, il n'en reste pas moins que c'est php qui ouvre et ferme les fichiers. Et la il n'y a aucun doute, php ouvre sans broncher plusieurs fois le meme fichier en ecriture.
Donc j'aurais confondu, j'avais fait des écritures "atomiques" en php une inclusion de chaine assez longue et j'en ai conclu un peu vite que c'était apache.
Je vais refaire des tests intensifs avec trois clients et des "timeout" en javascript pour voir s'il y a des confusions.
Je ferais un retour sur cette liste
Démosthène
__marc.quinton__
Demosthene wrote:
Je vais refaire des tests intensifs avec trois clients et des "timeout" en javascript pour voir s'il y a des confusions.
Je ferais un retour sur cette liste
oui, je suis intéressé, et j'espere ne pas me tromper, mais peu importe, il faut savoir se remettre en question. tu pourras aussi donner la methode de test.
et puis pourquoi un test intensif. Il suffit de provoquer les collisions :
* au moins 2 clients, * qui ouvrent un fichier en ecriture, * puis ecrivent dans ce fichier, * et qui font un sleep aléatoire de quelque seconde à 10 secondes, * referment le fichier, * et verifient que le contenu correspond a ce qu'il y a dedans,
voila pour l'idée.
* plus il y a de client, plus le risque est grand * plus le delai est grand plus il y a de risque de collision et moins l'opération semble atomique.
par la suite, si on voit qu'il y a un défaut, il suffit de gerer un lock ; J'ai ecrit une classe qui le fait tres bien dont les sources sont disponibles sur ce groupe.
et verifier qu'avec le lock, il n'y a pas perte d'intégrité de données.
Ce qui peut etre ecrit dans le fichier, c'est a vous de voir. * le pid, * des lignes avec par prossessus, * pid=valeur;autre-valeur=random
Demosthene wrote:
Je vais refaire des tests intensifs avec trois clients et des "timeout"
en javascript pour voir s'il y a des confusions.
Je ferais un retour sur cette liste
oui, je suis intéressé, et j'espere ne pas me tromper, mais
peu importe, il faut savoir se remettre en question. tu pourras
aussi donner la methode de test.
et puis pourquoi un test intensif. Il suffit de provoquer
les collisions :
* au moins 2 clients,
* qui ouvrent un fichier en ecriture,
* puis ecrivent dans ce fichier,
* et qui font un sleep aléatoire de quelque seconde à 10 secondes,
* referment le fichier,
* et verifient que le contenu correspond a ce qu'il y a dedans,
voila pour l'idée.
* plus il y a de client, plus le risque est grand
* plus le delai est grand plus il y a de risque de collision
et moins l'opération semble atomique.
par la suite, si on voit qu'il y a un défaut, il suffit de gerer
un lock ; J'ai ecrit une classe qui le fait tres bien dont les
sources sont disponibles sur ce groupe.
et verifier qu'avec le lock, il n'y a pas perte d'intégrité
de données.
Ce qui peut etre ecrit dans le fichier, c'est a vous de voir.
* le pid,
* des lignes avec par prossessus, * pid=valeur;autre-valeur=random
Je vais refaire des tests intensifs avec trois clients et des "timeout" en javascript pour voir s'il y a des confusions.
Je ferais un retour sur cette liste
oui, je suis intéressé, et j'espere ne pas me tromper, mais peu importe, il faut savoir se remettre en question. tu pourras aussi donner la methode de test.
et puis pourquoi un test intensif. Il suffit de provoquer les collisions :
* au moins 2 clients, * qui ouvrent un fichier en ecriture, * puis ecrivent dans ce fichier, * et qui font un sleep aléatoire de quelque seconde à 10 secondes, * referment le fichier, * et verifient que le contenu correspond a ce qu'il y a dedans,
voila pour l'idée.
* plus il y a de client, plus le risque est grand * plus le delai est grand plus il y a de risque de collision et moins l'opération semble atomique.
par la suite, si on voit qu'il y a un défaut, il suffit de gerer un lock ; J'ai ecrit une classe qui le fait tres bien dont les sources sont disponibles sur ce groupe.
et verifier qu'avec le lock, il n'y a pas perte d'intégrité de données.
Ce qui peut etre ecrit dans le fichier, c'est a vous de voir. * le pid, * des lignes avec par prossessus, * pid=valeur;autre-valeur=random
