2

This is more of a conceptual question. I have a working application that allows users to upload a CSV file of addresses, then parses the data into an Array of Address objects, then validates each Address object against certain rules (certain fields are required, etc.). The page then displays any addresses that failed validation, giving the user the ability to edit or delete each.

Right now, I am storing the entire Array in a SESSION variable, assigning each Address an Id value, then updating each Address in the SESSION Array when the user makes edits and submits the form.

I'm trying to think of a way to do this without using the SESSION scope, or using a physical database, or physical file. Any ideas?

Eric Belair
  • 10,574
  • 13
  • 75
  • 116
  • FYI, like I said, it's working now using the SESSION scope, I am just trying to get away from using the SESSION scope where ever possible, and it just seems silly to me to use the SESSION scope for an application that has only one page. I'm tiring of having to maintain the SESSION scope. – Eric Belair Feb 28 '12 at 18:55
  • What's the reasoning behind not wanting to use a physical database? They are great for tasks like this. Using the session scope like that will cost a lot of memory. You'd want to keep your session timeouts low. – Mike Causer Feb 29 '12 at 04:41

3 Answers3

1

If you don't use a physical database you would have to use some sort of persistent scope. That means the SESSION scope, the CLIENT scope (if you have that enabled), the APPLICATION scope, or the SERVER scope. But I think the safest way (as all those persistent scopes are cleared if your server goes down) is to store them in a database -- whether that database is a RDBMS, text file, or a Verity or Solr collection. I apologize in advance if that doesn't answer your question.

David Faber
  • 12,277
  • 2
  • 29
  • 40
1

The data needs to be stored / preserved somewhere if you want to work with it across multiple requests. Aside from the options your question rules out (session, database, file), I can think of two other (non-ideal) options:

  1. External cache mechanism like memcached -- not necessarily recommended because it's inherently volatile and doesn't guarantee to preserve your data

  2. Pass the contents of the CSV around from request to request, e.g. via hidden FORM containing JSON -- not recommended if the CSV can get large

Personally, my colleagues and I tend to use temporary database storage for this type of issue.

Paul Karlin
  • 840
  • 7
  • 21
1

I don't know anything about your requirements or use cases, but if you can depend on your users to have modern browsers, another viable option might be HTML5 localStorage.

Skimming some of the questions might give you some ideas.

Ken Redler
  • 23,863
  • 8
  • 57
  • 69