in reply to Structure of a custom class (using Apache::Session)

What do you mean by "singular data store connection"? All this class seems to do is to add a layer of indirection over Apache::Session::MySQL. That can be useful, but I fail to see what it's trying to accomplish here. Could you elaborate a bit?

Off topic, using map in a void context is weird if not error-prone or slow. You should replace
map{$self->{session}->{$_} = $args{$_}} keys %args;
with
$self->{session}->{$_} = $args{$_} foreach keys %args;

Replies are listed 'Best First'.
Re^2: Structure of a custom class (using Apache::Session)
by jeyroz (Monk) on Jun 15, 2005 at 18:55 UTC

    Thanks for your reply!
    By "singular data store connection" (bad phrasing) I simply meant specifying the connection information in one location (the class) rather than in every script that uses the session data. Keeping that info in one place was the original reason for creating a "layer of indirection" ... but I absolutely agree, in its current state, the class doesn't provide much benefit. It was that realization that prompted me to post and find out if I should continue with its development or scrap it.

    Also, thank you for the "map" advice ... made the change in my code.

    author => jeyroz

[reply]
      I simply meant specifying the connection information in one location (the class)

      um? The connection info isn't in the class. It's still in the class's user, just like it would be if Apache::Session::MySQL had been used directly.

      my $session_obj = Local::WPSession->new(dbh => $dbh, id => $sid);
#                                              ^^^^

      [download]

      If you want to move the info needed to create the dbh into Local::WPSession (and possibly even create the dbh within the new class as well), why not make Local::WPSession inherit from Apache::Session::MySQL and simply override the constructor? That way, the user will be able to access all of Apache::Session::MySQL's methods without forcing you to recreate the interface or to create a new interface.

[reply]
[d/l]

        Ikagami, thanks again for your response!

        I am indeed passing $dbh into my class but the connection details are specified in the class itself. While it's convenient to use my existing db handle in this example, it won't always be available to pass. In that case I would certainly move the actual db connection into the class itself ... my fault for not stating that. Also, there is a possibility that the session data may not be stored in the same database that the application uses. In this case there would be a bit more information needed to establish the connection. I figured keeping this separate would save me some touble. Let me know if this still seems wasteful.

        I like your suggestion to simply override the constructor.

        author => jeyroz

[reply]
      I think having the connection/configuration information all in one place is a decent reason for wrapping Apache::Session::* with an class. I would still specify database connection information in a separate config file since the session isn't the only place in your code that probably needs a database right? I also prefer having an OO access rather than playing directly with the tied hash, but that may just be a personal preference.

      Before you go too far though, I would look at Apache::SessionManager and see if it's doing the same thing that you're looking for (if you're using mod_perl)

      -- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier
[reply]

In Section Seekers of Perl Wisdom