Si deve fare attenzione ad usare la sessione per dati grossi perché per
default la sessione è memorizzata nei cookie. Oltre un certo limite si
deve cambiare il SessionStore. Tuttavia c’è davvero qualcosa che non va
in quest’approccio: mandare i dati avanti e indietro per la rete è
sicuramente meno efficiente che memorizzarli sul server.
Se ci pensate, il luogo naturale per memorizzare grandi quantità di dati
è il database del server o il suo file system. Memorizzando lì dentro
@@u_righe poi si riesce a far viaggiare in rete solo un id numerico
dentro a delle GET. E’ quello che si fa tutto il tempo con i metodi REST
dei controller Rails. Perché cambiare?
Quando anni fa passai da Struts (Java) a Rails mettevo anch’io tanti
dati in sessione. Poi dopo aver scritto un session store che si
appoggiava al database mi resi conto che era inutile: tanto vale avere
delle tabelle con cui memorizzare quel che serve ed usare un id per
farvi riferimento. Attenzione ad avere lo user_id nella tabella, ed
usarlo per i controlli sull’accesso.
A proposito, usando @@u_righe si deve pensare ad un modo per impedire ad
utenti diversi del sistema a non pasticciarsi i dati l’uno con l’altro.
Paolo
Fabrizio R. wrote in post #1079812:
Presumo tu stia iniziando a studiare Ruby oppure Rails, continua cos,
non mollare!
Quello che dici, ovvero usare la memoria del processo per la persistenza
dei dati, una soluzione che in un ambie nte i produzione non molto
praticata. Per questo alcuni di noi, me compreso, non capivano la
domanda.
Quello che dici te :
- Ho un controller con due azioni: in una setto un array come variabile
di classe del controller, nell’altra leggo quell’array.
Una delle ragioni per cui non si fa che il processo della tua
applicazione pu ricevere, tra la tua prima richiesta e la seconda, la
prima richiesta di un altro utente, che pu cambiare quel valore.
Se si tratta di un valore globale questo pu non essere un problema. Ad
ogni modo in questo caso si parla cache. Rails dispone di API per la
gestione della cache:
Caching with Rails: An Overview — Ruby on Rails Guides
E’ possibile configurare Rails per usare backend diversi per il caching
e, tra questi, guarda caso, c’ anche il memory_store, che fa quello che
abbiamo detto pocanzi, ovvero usa la memoria del processo per mantenere
il valori tra le richieste.
Ti consiglio per cose del genere di prendere in considerazione anche una
variabile di sessione.
-f