Thread: OT: Apache::Session::DBI vs postgresql? --help
LONG VERSION:
having burned the manpages into my eyelids, and coming up short,
i though i'd bug the community at large with this--surely
someone listening here is using apache with postgres to do some
handy user-tracking...?
man Apache::Session::DBI
refers me to
man Apache::Session::DBIStore
which says
To use this module, you will need these columns in a table
called 'sessions':
id char(16)
length int(11)
a_session text
which might be ducky for mysql, but on postgresql (7.0.3 anyhow)
"length" is illegal as a field name.
i then manage to run across
man Apache::Session::Store::Postgres
which says
To use this module, you will need at least these columns
in a table called 'sessions':
id char(32) # or however long your session IDs are.
a_session text # This has an ~8 KB limit :(
and then
man Apache::Session::Postgres
tells me to try
use Apache::Session::Postgres;
#if you want Apache::Session to open new DB handles:
tie %hash, 'Apache::Session::Postgres', $id, {
DataSource => 'dbi:Pg:dbname=sessions',
UserName => $db_user,
Password => $db_pass,
Commit => 1
};
which yields only a
Can't locate object method "TIEHASH" via package
"Apache::Session::Postgres" at doomedtofail.pl line 10.
even though Apache::Session::Postgres "@ISA" Apache::Session,
which means it should inherit the TIEHASH method there.
--
(((
if, as an ordinary user, i use "Apache::Session::DBI" i get
Permission denied at /usr/local/lib/site_perl/Apache/Session/SysVSemaphoreLocker.pm line 63.
before anything gets 'tied'; if i try it as root, i get past the
permission problem, but then stumble into
DBD::Pg::st execute failed: ERROR: Unterminated quoted string
the investigation of which shows it's preparing a select
statement that's looking for the unfriendly "length" field --
but i digress.
)))
SHORT VERSION: (the question)
==========================================================
i've not figured out how to get Apache::Session::Postgres
or Apache::Session::Store::Postgres to do their thing --
how does a MOD_PERL script get its hooks into POSTGRES via
Apache::Session::DBI ?
==========================================================
i don't really want to revert to the manual approach:
use Apache::Session::Store::Postgres;
my $store = new Apache::Session::Store::Postgres;
$store->insert($ref);
$store->update($ref);
$store->materialize($ref);
$store->remove($ref);
i'm sure the "tie %hash,'Apache::Session::DBI',undef" form
really does work as documented -- so what'd i miss?
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Short version:
Apache::Session is a generic class to store a session in some place and
store locking information of session in another place. You can plug in the
classes which detail where the session is stored/locked.
Apache::Session::DBIStore is apparently broken for postgres (due to length
issue). I whined once to maintainer about it, but he was concerned with
backwards compatibility and unwilling to change it. But its outdated
anyway, and you are supposed to use Apache::Session::Store::* classes.
The one you are supposed to use is Apache::Session::Store::Postgres, and
it should work. There's no 8k limit in postgres 7.1 on row length.
-alex
On Fri, 15 Jun 2001, will trillich wrote:
> LONG VERSION:
>
> having burned the manpages into my eyelids, and coming up short,
> i though i'd bug the community at large with this--surely
> someone listening here is using apache with postgres to do some
> handy user-tracking...?
>
> man Apache::Session::DBI
>
> refers me to
>
> man Apache::Session::DBIStore
>
> which says
>
> To use this module, you will need these columns in a table
> called 'sessions':
>
> id char(16)
> length int(11)
> a_session text
>
> which might be ducky for mysql, but on postgresql (7.0.3 anyhow)
> "length" is illegal as a field name.
>
> i then manage to run across
>
> man Apache::Session::Store::Postgres
>
> which says
>
> To use this module, you will need at least these columns
> in a table called 'sessions':
>
> id char(32) # or however long your session IDs are.
> a_session text # This has an ~8 KB limit :(
>
> and then
>
> man Apache::Session::Postgres
>
> tells me to try
>
> use Apache::Session::Postgres;
>
> #if you want Apache::Session to open new DB handles:
>
> tie %hash, 'Apache::Session::Postgres', $id, {
> DataSource => 'dbi:Pg:dbname=sessions',
> UserName => $db_user,
> Password => $db_pass,
> Commit => 1
> };
>
> which yields only a
>
> Can't locate object method "TIEHASH" via package
> "Apache::Session::Postgres" at doomedtofail.pl line 10.
>
> even though Apache::Session::Postgres "@ISA" Apache::Session,
> which means it should inherit the TIEHASH method there.
>
> --
>
> (((
> if, as an ordinary user, i use "Apache::Session::DBI" i get
>
> Permission denied at /usr/local/lib/site_perl/Apache/Session/SysVSemaphoreLocker.pm line 63.
>
> before anything gets 'tied'; if i try it as root, i get past the
> permission problem, but then stumble into
>
> DBD::Pg::st execute failed: ERROR: Unterminated quoted string
>
> the investigation of which shows it's preparing a select
> statement that's looking for the unfriendly "length" field --
> but i digress.
> )))
>
> SHORT VERSION: (the question)
>
> ==========================================================
> i've not figured out how to get Apache::Session::Postgres
> or Apache::Session::Store::Postgres to do their thing --
> how does a MOD_PERL script get its hooks into POSTGRES via
> Apache::Session::DBI ?
> ==========================================================
>
> i don't really want to revert to the manual approach:
>
> use Apache::Session::Store::Postgres;
> my $store = new Apache::Session::Store::Postgres;
> $store->insert($ref);
> $store->update($ref);
> $store->materialize($ref);
> $store->remove($ref);
>
> i'm sure the "tie %hash,'Apache::Session::DBI',undef" form
> really does work as documented -- so what'd i miss?
>
>
>> To use this module, you will need these columns in a table
>> called 'sessions':
>>
>> id char(16)
>> length int(11)
>> a_session text
>>
>> which might be ducky for mysql, but on postgresql (7.0.3 anyhow)
>> "length" is illegal as a field name.
"length" is perfectly legal as a field name:
regression=# create table foo (f1 int, length int);
CREATE
The problem is that "int(11)", which is a MySQL-ism through and through;
there is no such construct in SQL92. We'd take "int", or "bigint", or
"int8", or "numeric(11)", or "decimal(11)" ...
regards, tom lane
On Fri, Jun 15, 2001 at 10:59:11AM -0400, Alex Pilosov wrote:
> Apache::Session is a generic class to store a session in some place and
> store locking information of session in another place. You can plug in the
> classes which detail where the session is stored/locked.
sentence one, i grok. sentence two i sorta suspect, but do not
comprehend.
> Apache::Session::DBIStore is apparently broken for postgres (due to length
> issue). I whined once to maintainer about it, but he was concerned with
> backwards compatibility and unwilling to change it. But its outdated
> anyway, and you are supposed to use Apache::Session::Store::* classes.
>
> The one you are supposed to use is Apache::Session::Store::Postgres, and
> it should work. There's no 8k limit in postgres 7.1 on row length.
<ignorance level="alarmingly embarrassing"> HOW? </ignorance>
i've been studying perl modules for several months and
it's still giving me the heebie-jeebies, nightmares, the works.
from looking at the Apache::Session::Store::Postgres code, it
sure looked like what i was after, as you suggest -- but how do i
tell Apache::Session to use that instead of A:S:DBIStore?
the manual sez--
IMPLEMENTATION
The way you implement Apache::Session depends on what you
are trying to accomplish. Here are some hints on which
classes to use in what situations
Single machine *nix Apache
Use DBIStore and SysVSemaphoreLocker
now if they'd tell me HOW (or someone shows me that they indeed
have done so) i'd get started. :)
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Actually, I just tried your original example, and it worked for me:
use Apache::Session::Postgres;
#if you want Apache::Session to open new DB handles:
tie %hash, 'Apache::Session::Postgres', $id, {
DataSource => 'dbi:Pg:dbname=sessions',
UserName => $db_user,
Password => $db_pass,
Commit => 1
};
(all works fine)
I think your problem is using wrong versions of Apache::Session. Make sure
you upgrade to latest (1.53). You should _not_ even have had
Session::DBIStore, its gone a long time ago.
And I was mistaken, its kind of a pain to use A:S:Store::Postgres, you are
supposed to use A:S:Postgres :)
-alex
On Fri, 15 Jun 2001, will trillich wrote:
> On Fri, Jun 15, 2001 at 10:59:11AM -0400, Alex Pilosov wrote:
> > Apache::Session is a generic class to store a session in some place and
> > store locking information of session in another place. You can plug in the
> > classes which detail where the session is stored/locked.
>
> sentence one, i grok. sentence two i sorta suspect, but do not
> comprehend.
>
> > Apache::Session::DBIStore is apparently broken for postgres (due to length
> > issue). I whined once to maintainer about it, but he was concerned with
> > backwards compatibility and unwilling to change it. But its outdated
> > anyway, and you are supposed to use Apache::Session::Store::* classes.
> >
> > The one you are supposed to use is Apache::Session::Store::Postgres, and
> > it should work. There's no 8k limit in postgres 7.1 on row length.
>
> <ignorance level="alarmingly embarrassing"> HOW? </ignorance>
>
> i've been studying perl modules for several months and
> it's still giving me the heebie-jeebies, nightmares, the works.
>
> from looking at the Apache::Session::Store::Postgres code, it
> sure looked like what i was after, as you suggest -- but how do i
> tell Apache::Session to use that instead of A:S:DBIStore?
>
> the manual sez--
>
> IMPLEMENTATION
> The way you implement Apache::Session depends on what you
> are trying to accomplish. Here are some hints on which
> classes to use in what situations
>
> Single machine *nix Apache
> Use DBIStore and SysVSemaphoreLocker
>
> now if they'd tell me HOW (or someone shows me that they indeed
> have done so) i'd get started. :)
>
>
On Sat, Jun 16, 2001 at 12:41:57AM -0400, Alex Pilosov wrote:
> Actually, I just tried your original example, and it worked for me:
> use Apache::Session::Postgres;
>
> #if you want Apache::Session to open new DB handles:
>
> tie %hash, 'Apache::Session::Postgres', $id, {
> DataSource => 'dbi:Pg:dbname=sessions',
> UserName => $db_user,
> Password => $db_pass,
> Commit => 1
> };
> (all works fine)
>
> I think your problem is using wrong versions of Apache::Session. Make sure
> you upgrade to latest (1.53). You should _not_ even have had
> Session::DBIStore, its gone a long time ago.
ah. that made a big difference! thanks.
the manpages for Apache::Session::DBI still say that it
uses Apache::Session::DBIStore for its grunt work. whereas
normal db lookup scripts can
use DBI
which then hooks into the needed DBD::<whatever> according to
the datasource pattern; i guess Apache::Session::DBI doesn't do
that... which is why we have to specify
use Apache::Session::Postgres
*and*
...DataSource=>'dbi:Pg:dbname=something'...
which seems a bit unmodular, to coin a phrase.
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
On Sat, 16 Jun 2001, will trillich wrote: > the manpages for Apache::Session::DBI still say that it > uses Apache::Session::DBIStore for its grunt work. whereas You still have the old manpages (and probably old scripts). CPAN's upgrades don't delete files that belong to old modules. > normal db lookup scripts can > use DBI > which then hooks into the needed DBD::<whatever> according to > the datasource pattern; i guess Apache::Session::DBI doesn't do > that... which is why we have to specify > use Apache::Session::Postgres > *and* > ...DataSource=>'dbi:Pg:dbname=something'... > which seems a bit unmodular, to coin a phrase. That's because unfortunately, the database schema that needs to be used is dependent on the type of a database, so you do need to tell which specific database you use. -alex
Alex Pilosov wrote:
>
> On Sat, 16 Jun 2001, will trillich wrote:
>
> > the manpages for Apache::Session::DBI still say that it
> > uses Apache::Session::DBIStore for its grunt work. whereas
> You still have the old manpages (and probably old scripts).
> CPAN's upgrades don't delete files that belong to old modules.
good point -- what's the Recommended Procedure, there?
> > normal db lookup scripts can
> > use DBI
> > which then hooks into the needed DBD::<whatever> according to
> > the datasource pattern; i guess Apache::Session::DBI doesn't do
> > that... which is why we have to specify
> > use Apache::Session::Postgres
> > *and*
> > ...DataSource=>'dbi:Pg:dbname=something'...
> > which seems a bit unmodular, to coin a phrase.
> That's because unfortunately, the database schema that needs to be used is
> dependent on the type of a database, so you do need to tell which specific
> database you use.
but isn't that what
$DBD_Driver = ($DataSource =~ m/^dbi:(\w+):/)[0]
would do? with old-fashioned "DBI" we just
use DBI;
my $dbh = DBI->connect("dbi:TheDriverSpec:database-connect-string");
and the DBD::TheDriverSpec is loaded automatically.
--
mailto:will@serensoft.com
http://www.dontUthink.com/
On Mon, 18 Jun 2001, will trillich wrote:
> Alex Pilosov wrote:
> >
> > On Sat, 16 Jun 2001, will trillich wrote:
> >
> > > the manpages for Apache::Session::DBI still say that it
> > > uses Apache::Session::DBIStore for its grunt work. whereas
> > You still have the old manpages (and probably old scripts).
> > CPAN's upgrades don't delete files that belong to old modules.
>
> good point -- what's the Recommended Procedure, there?
None, don't use old files ;)
> > That's because unfortunately, the database schema that needs to be used is
> > dependent on the type of a database, so you do need to tell which specific
> > database you use.
>
> but isn't that what
>
> $DBD_Driver = ($DataSource =~ m/^dbi:(\w+):/)[0]
>
> would do? with old-fashioned "DBI" we just
>
> use DBI;
> my $dbh = DBI->connect("dbi:TheDriverSpec:database-connect-string");
No. The schema is different, and the way you store things in database is
actually different for different types of database. (Such as on certain
databases Session code may use large objects, etc). DBI is to do _same_
things across many databases. Apache::Session needs to do different things
for different databases.
-alex
On Sat, Jun 16, 2001 at 12:41:57AM -0400, Alex Pilosov wrote:
> Actually, I just tried your original example, and it worked for me:
> use Apache::Session::Postgres;
>
> #if you want Apache::Session to open new DB handles:
>
> tie %hash, 'Apache::Session::Postgres', $id, {
> DataSource => 'dbi:Pg:dbname=sessions',
> UserName => $db_user,
> Password => $db_pass,
> Commit => 1
> };
> (all works fine)
>
> I think your problem is using wrong versions of Apache::Session. Make sure
> you upgrade to latest (1.53). You should _not_ even have had
> Session::DBIStore, its gone a long time ago.
nice catch, there, by the way. that fixed me right up.
i just wonder, as things get upgraded and phased out, we install
new copies over the old, but some of the phased-out old just sit
there, looking useful, waiting for an innocent victim to stumble
across and try something that really screws things up... maybe i
could zap any *::*.pm that haven't been accesed in the past 180
days or so?
but then when i do "perl -MCPAN -e shell" and try to install
something new, it often requires perl 5.6 which, being a debian
potato stalwart, i'm loath to join with. the debian packaging
system is good at letting you select which release of packages
to pursue (stable, testing, unstable) -- i only with CPAN had
that facility... <sigh>
--
I figure: if a man's gonna gamble, may as well do it
without plowing. -- Bama Dillert, "Some Came Running"
will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!