Where to save temp data?

[Heinz Strunk]

Hello,

I need some advice. I have a form that has data from 4 different tables
and about 10 values to save and keep until the form is finally sent.

Where would you save the 10 values (all strings or integers, of course)?
Session? Cookie? Pass them around as parameter?

I'm a bit confused and would highly appreciate any suggestions.

Thanks!
--
Posted via http://www.ruby-forum.com/.

[Marnen Laibow-Koser]

Heinz Strunk wrote:
> Hello,
>
> I need some advice. I have a form that has data from 4 different tables
> and about 10 values to save and keep until the form is finally sent.
>
> Where would you save the 10 values (all strings or integers, of course)?
> Session? Cookie? Pass them around as parameter?

If it's only one request cycle, there's no real need to save temp data.
What are you trying to do?

>
> I'm a bit confused and would highly appreciate any suggestions.
>
> Thanks!

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org

[Heinz Strunk]

Marnen Laibow-Koser wrote:
>
> If it's only one request cycle, there's no real need to save temp data.
> What are you trying to do?
>

That's exactly my problem, otherwise I would be using variables. It's
many request cycles going back and forth that's why I need a proper way
to save some data. I'm doing it by passing parameters but it's confusing
and I don't like parameter when handling so many variables.

[Hassan Schroeder]

On Fri, Nov 6, 2009 at 3:23 PM, Heinz Strunk
<rails-mai...@andreas-s.net> wrote:

> That's exactly my problem, otherwise I would be using variables. It's
> many request cycles going back and forth that's why I need a proper way
> to save some data. I'm doing it by passing parameters but it's confusing
> and I don't like parameter when handling so many variables.

Is there any chance your form data needs to persist across sessions,
(as in user leaves, comes back, resumes filling in unfinished form)?

If not, you could save your variables in a hash in session. Otherwise
I would create a Form model and save it to the DB.

FWIW,
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
twitter: @hassan

[Heinz Strunk]

Hassan Schroeder wrote:
>
> Is there any chance your form data needs to persist across sessions,
> (as in user leaves, comes back, resumes filling in unfinished form)?
>
> If not, you could save your variables in a hash in session. Otherwise
> I would create a Form model and save it to the DB.
>

No, user doesn't leave. It just could end up in many request cycles.
Didn't have the Session a very small amount of data it can save?

[Hassan Schroeder]

On Sat, Nov 7, 2009 at 12:49 AM, Heinz Strunk
<rails-mai...@andreas-s.net> wrote:

> No, user doesn't leave. It just could end up in many request cycles.
> Didn't have the Session a very small amount of data it can save?

That depends on how you're handling sessions, but the more I think
about it, I'd just go with the Form object and saving changes to the
DB across requests.

[Colin Law]

2009/11/6 Heinz Strunk <rails-mai...@andreas-s.net>:

If you are only talking about a few hundred bytes or less then you can
certainly save it in the session. The alternative is to use fields in
something like the User table, assuming there is one.

Colin

[Heinz Strunk]

Well, most of it is actullay not any data that's going to be saved in
the database. I need to know various numbers like "current number of
users", "maximum number of users", "ids of the users" and stuff like
that.

So I guess I should go for the session?

[Colin Law]

2009/11/9 Heinz Strunk <rails-mai...@andreas-s.net>:

>
> Well, most of it is actullay not any data that's going to be saved in
> the database. I need to know various numbers like "current number of
> users", "maximum number of users", "ids of the users" and stuff like
> that.
>
> So I guess I should go for the session?

What do you mean by "current number of users"? Do you mean how many
users are logged on? I got the impression in your original post that
we were talking about data entered by the user. How do you know how
many users are currently logged on? Remember that a session is on a
user by user basis. If you want to remember data across users I think
you will have to put it in the db.

Colin

[Peter De Berdt]

Indeed, with the ActiveRecord store, you could count the number of sessions that were active in the last x minutes, but even that's just an approximate value. With the CookieStore, you don't have a way to determine the number of active users that easily (which certainly doesn't mean you have to use the ActiveRecordStore again).

The only reliable way is maintaining a persistent connection to the server (using Juggernaut or Comet for example). When that connection is terminated, the user has logged off (it will even provide instant feedback when the window is closed, but the session is still persisting in the user's browser).

Best regards

Peter De Berdt

[Heinz Strunk]

No no no, you understood me wrong. It's just a form where you can add
users to the object that is being created. It's a form, you click on add
user you go to another page, add as many users as you want, go back to
the main form.
I need to know how many users have been added, which ones and if the
maximum is reached.

Is it more clear now?

[Colin Law]

2009/11/9 Heinz Strunk <rails-mai...@andreas-s.net>:

>
> No no no, you understood me wrong. It's just a form where you can add
> users to the object that is being created. It's a form, you click on add
> user you go to another page, add as many users as you want, go back to
> the main form.
> I need to know how many users have been added, which ones and if the
> maximum is reached.
>
> Is it more clear now?

Yes, in that case I would use the session, if you are really sure you
can't just update the db as you go along. What is the issue with just
updating the db as you go? The user will get really hacked off if he
spends half an hour entering multiple forms only to lose it all when
he loses connection for some reason.

Colin

[Heinz Strunk]

Well, good point but I'm not sure if I unerstood what you exactly mean
by update db as you go. The group and it's users (which are being added
in the sub form) have a m:n-relation so you'd create that relaion for
each and every user being added and delete it again if something goes
wrong or the user hits the cancel button? Looks like a lot of
unnecessary db traffic to me. Or would you create another table only for
the temp data?

[Colin Law]

2009/11/9 Heinz Strunk <rails-mai...@andreas-s.net>:

I do not know enough about the application to say much more. I was
suggesting updating the actual data rather than a temp table, but it
was only a suggestion. I generally would suggest to do things the
easiest way initially and only complicate it it if becomes necessary,
though which is the easy way in your case I do not know. Certainly
don't worry about the db traffic unless it becomes an issue.

Whichever route you go down make sure you have tests in place so you
can refactor later and know it still works.

Colin

[Heinz Strunk]

Colin Law wrote:
>
> I do not know enough about the application to say much more. I was
> suggesting updating the actual data rather than a temp table, but it
> was only a suggestion. I generally would suggest to do things the
> easiest way initially and only complicate it it if becomes necessary,
> though which is the easy way in your case I do not know. Certainly
> don't worry about the db traffic unless it becomes an issue.
>
> Whichever route you go down make sure you have tests in place so you
> can refactor later and know it still works.
>
> Colin

Alright, thanks a lot to all of you! I'll keep both solutions in mind
and see what's easier to use.