At 09:33 PM 6/16/2005, Mark Stosberg wrote:
On 2005-06-17, Ron Savage <[EMAIL PROTECTED]> wrote:
>
> Apache::Session, although unsupported, may contain useful ideas.
> Likewise, Apache::Session::Manager and Apache::SessionManager.

Noted.

>> operations on one table. It's unhelpful that it dumps the whole
>> session object into one database column. This limits the usefulness
>

Hi,

I really think it is just the opposite. In my opinion the job of the session is to keep state as easily as possible, it should be one *thing* likely an extensible data structure that when you choose can be split out into its parts and do what you like with it. It should not be treated like organized information because it can change so quickly, it is just data. I really like the way php handles it, it is one of the only things about PHP that I do really like.(Yes the temp file stuff is not the greatest, make sure you have the temp space to match your traffic :)) With Perl we use Storable and a standard format for the data we put in. We freeze that structure then insert it into the session table that also has some pieces of info pulled out of the session for the sake of easy accessibility. For example the user's email address and yes a timestamp :) The main thing for me is to be able to add session variables without having to do anything much and they will be carried through to where they are needed.

Not sure how relevant this is to the topic, but it seemed odd to me to be talking about how many db fields a session should occupy.. So another way to put it, if you want to think of a session table, itt should have one field with unorganized very changeable data, and any other fields should be things that are not likely to change. We will always need the person's name and email address in our order system for example, but we might not always require lot of other fields depending on the situation. The session best works for me when those transient bits are in the session and not in db fields. I HATE changing tables, it makes me feel like I screwed up the db design to begin with..


Thanks,

Eric


> Ahh, I personally find that feature effortless, but I'm aware of your
> preference for field per column.

I have used session handling for a number projects now. I think I have
always needed just 1 to 3 additional columns.

>> - The storage focus will database-centric, not file-centric. Use
>> DBD::SQLite if you don't want/have a real DB. This will make it
>
> OK - but my tests showed (to my satisfaction, if to no-one else's) the
> SQLite is unreliable and therefore useless under Windows.
>
> Frankly, I would never use it on any platform after what I've seen,
> but hey, if it works for you, use it.

I don't use SQLite myself, but I keep seeing it used it lots of places.
There is also DBD::CSV, which just might work for this purpose.

> I use files under GNU/Linux only because I've never managed to get
> CGI::Session to work with Postgres there. I'd certainly be very happy
> indeed if this new module worked under all OSes I have to deal with.

Curious. There is also currently my CGI::Session::PureSQL, which is
build to work with PostgreSQL, but not tested on Windows.

> Anyway, if it's going to be as good as Data::FormValidator, go for it!

I didn't design or code a lot of DFV, but I appreciate your enthusiasm!
I /am/ interested in feedback about the changes I proposed in the DFV 4.0
release on CPAN.

There's lots of new callbacks stuff being used in DFV 4.0. It seems to
be a theme around here...

    Mark

--
http://mark.stosberg.com/


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
             http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to