Newsgroup: it.comp.www.php
Titolo: Pgsql + Views + php + persistent connection

Ciao a tutti.
Dovrei implementare una specie di carrello della spesa.
Da pagina a pagina mi trovo però con la necessità di ricordarmi quali dati
l'utente ha selezionato.
Potrei in effetti ricordarmi solo delle chiavi primarie degli articoli ma
questo mi provoca il problema
del recupero dei dati. Cioè dovrei fare n select su n articoli (articoli che
dovrebbero essere 200+)
Potrei salvare i dati come oggetti e registrarli come variabili di sessione,
cosa troppo grande per + di 200 articoli.
La mia idea è quella di utilizzare le tabelle temporanee.
Se usassi le View in postgresql potrei risolvere il mio problema.
Ecco allora perchè scrivo al ng:
Dovrei usare una connessione persistente.
Su quella connessione poi creo delle viste con i dati che mi interessano.
Domande:
la connessione persistente si propaga da pagina a pagina?
cioè se un utente pippo si connette su pagina1 e poi si connette su pagin2
gli verrà ridata la SUA di connessione?
(oppure è solo una risorsa di connessione "riciclata")
è impossibile vero, che una connessione persistente sia recuperata da
un'altro utente topolino?
se nell'ambito di una connessione persistente creo delle viste quelle sono
associate solo a quella connessione?
cioè se creo una vista "tab_tmp", questa è propria solo di quella
connessione?
se chiudo una connessione persistente allora le relative viste create su
quella connessione vengono droppate?
una conn persistente va in time out? cioè se l'utente pippo lascia il suo
browser aperto 10 ore e poi torna la connessione
è ancora attiva? e quindi le viste connesse essitono ancora?
ma se la connessione non va in timeout avremo il problema delle connessioni
massime aperte in simultanea supportate.
Cosa mi consigliate?
thnx all

 
personalmente risolverei con i codici degli articoli nelle sessioni.
200 articoli non sono molti e non č cosě pesante fare una query per pagina.
Sul discorso delle connessioni persistenti non saprei dirti
ciao
Alesi_27


bhč ma cosě dovrei effettuare 200 queries no?
ex:
id_articolo  nome         descrizione                   prezzo
10             "banane"    "banane svizzere"        "100.000"
da questo voglio passare gli id da pg a pg.
quindi memorizzo in un array tutti gli id selezionati (ex: 10-11-15-9-...)
alla fine prň voglio far vedere un resoconoto, anzi voglio calcolarmi il
prezzo finale
non dovrei fare una query cosě:
foreach($lista as $value){//200 quires
    select * from articoli where id=$value
    ....
    memorizzo prezzo
}
mi sbaglio?
Pensavo di abbandonare le viste e le connesioni persistenti
ho letto che non + č detto che da pg a pg venga per forza ridata la stessa
connessione.
Se creassi una tabella apposta per gli ordini potrei tener traccia da pg a
pg delle selezioni dell'utente.
ordini_utente (n:n)
utente    id_articolo
1010    10
alla fine dell'operazione cancello gli ordini per snellire il db
cosě potrei dare un'idea di persistenza.
che ne pensate

 
e se all'utente manca la corrente oppure chiude il browser senza 
"preavviso" ??
non č consigliabile tale procedura.
ciao
Alesi_27

 Cosa mi consigliate?
ci sono moduli che sfruttano l'inserimento di dati di sessione 
direttamente su db (ho letto qualcosa du google ma mai toccato con 
mano). prova a vedere se trovi qualcosa con "php postgres session 
handler" o cose così.
oppure salva tutto su sessione.
oppure (meglio) cerca di rivedere l'application logic in modo da non 
dover salvare per forza tutti quei dati.
vedi anche
http://www.php.net/manual/it/function.pg-pconnect.php
http://www.php.net/manual/it/features.persistent-connections.php
ciao
-- 
punkarruso


si mi sa che mi sono spiegato male
la tabella non viene creata per ogni utente
ma è una tabella spedizioni
questa continene i potenziali ordini in sospeso.
quindi ordini legati all'utente
tramite questo posso gestire un carrello "pesante" e modificarlo in base
alle esigenze


ti ringrazio molto.
mi sa che evito l'utilizzo di connessione persistente.
pensavo semplicemente di appoggiarmi ad una tabella spedizioni.
Questa contiene l'id utente + id articoli selezionati.
Attraverso un paio di join ricavo tutti i dati che voglio.
poi ho come vantaggio che simulo la persistenza,
infatti se l'utente registrato se ne va e torna gli ridň lo stesso carrello
se vuole modificare, eliminare item sul carrello basta eliminare una row dal
db.
Una volta che l'ordine č stato effettuato elimino le row associate a quel
id.
(cmq non č un e-commerce č qualcosa di un pň + complicato perň l'idea base č
simile)
Grazie

l'utente ha selezionato.
Crei un file temporaneo per ciascun utente, contenente il serialize()
dei dati. In pratica e' una sessione allargata :-)
Quando la sessione si estingue, uccidi il file.
Leonardo
-- 
Time's angles, mages tell, conceal a place
incredible, beyond the mundane mind;
night-shrouded and between the seas of space
dread creatures drift in the ageless winds.

 cosa troppo grande per + di 200 articoli.
Ti basta salvare gli identificativi degli articoli.
Avendo quelli sparare 200 query (che vanno a pescare 
i dati di un solo articolo alla volta) dentro una 
foreach non dovrebbe creare 
problemi. A meno che non utilizzi uno spectrum :-).
Considera che spesso CMS come postnuke we simili sul caricamento di
singole pagine generano molte più query e non sono certo lenti.
Se propro vuoi farti una pippa cranica e migliorare le prestazioni
puoi utilizzare la clausola
"where ID_ARTICOLO IN ('id1','Id2',etc etc) (non so se l'sql di
postgres la supporta, mysql ed oracle si...).
Se sulla IN hai il numero di elementi limitato (tipicamente 256) puoi
spezzare
il tutto in due o più query ed incollarle con la clausola UNION di
sql.
ciao

 alle esigenze
Le soluzioni con tabelle temporanee, temporary table ram etc etc si
usavano negli anni pionieristici di internet quando non c'erano
meccanismi di sessione.
Ma davano sempre casini, perchč dovevi suotarle, l'utente abbanonava
la sessione, etc etc.
Tendenzialmente preferisco evitarle come soluzione architetturale.
Su app server java o .net puoi aprire la connessione alla pagina 1 ,
archiviare gli ordini fino alla pagina N in una tabella senza
effettuare COMMIT della transazione, . Le l'utente completa l'ordine
committi, diversamente fai una rollback (o la fa in db implicitamente
se stacchi la connessione).
Php purtroppo non supporta (spero di essere smentitito, mi leverebbe
un discreto numero di rogne...) le connessioni persistenti con
transazioni su db su piů request (ergo, a fine esecuzione di scrpt o
dai commit o fai rollback, o la rollback te la fa il php...) , la
soluzione piů pulita quindi č usare le sessioni e non farsi spaventare
se i dati da portarsi dietro sono molti.
ciao