cgi-session-user — CGI::Session users mailing list

RE: [Cgi-session-user] Trouble with C::S::SQLite

[Sherzod R. <she...@ha...>]

> My most recent thinking on this is that we should add a "auto_flush"
option, which would currently default to false.

Since auto-flush isn't working for everybody, and since I'm not too sure
about having to call flush() manually, why don't we just synchronize at
each change made to the object? For those who have never had trouble
with auto-flush feature, we'll make it optional.

So here is what I'm proposing. When one does:

	$session->param('name', 'John Doe');

flush() would get called automatically from within param(), because a
change has been made to the object, and so for each method/activity that
changes the data table. I admit, it will not be very efficient when
param() is called many times during a particular instance of a program.
Even if param() is called just once, the object would still have to be
synchronized at least twice, first to update the atime(), and second to
update the data.

Having to update multiple keys at once should not be much concern
either, because param() method currently provides (I think, althought
may not be tested :) ) a way of updating multiple keys at batch,
reducing number of disk accesses), as in:

	$session->param(	key1	=> 'value1',
					key2	=> 'value2',
					#...
				);

This way CGI::Session will no longer rely on DESTORY().

For those who never had trouble with auto-flush feature, and for those
who don't mind having to call flush() manually, we'll provide
delay_flush() feature, which, if turned on, will delay flush() until the
object instance is destroyed, which is the current behavior, and the one
found not reliable for many. The proposed syntax may be one or all of:

	CGI::Session->delay_flush( 1 );
	# or
	$session->delay_flush( 1 );
	# or
	$session = CGI::Session->new(undef, undef, {delay_flush=>1});

We could construct some benchmark tests, with and without delay_flush().
If the difference in speed isn't much, we may not even need
delay_flush().

Any ideas?

--  
Sherzod Ruzmetov

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

On Mar 7, 2006, at 8:29 AM, Mark Stosberg wrote:

> On Tue, Mar 07, 2006 at 07:45:57AM -0600, Puneet Kishor wrote:
>
>> well, if I change
>>
>> 	new CGI::Session("driver:sqlite", $sid, {Handle=>$DBH})
>>
>> to either of the following two choices
>>
>> 	new CGI::Session("driver:sqlite", $sid,
>> {Handle=>DBI->connect("dbi:SQLite:dbname=/path/to/my.db")})
>> 	new CGI::Session("driver:sqlite", $sid,
>> {DataSource=>"dbi:SQLite:dbname=/path/to/my.db"})
>>
>> The session value gets stored in the database alright, but I get the
>> following error
>>
>>>> (in cleanup) Can't call method "commit" on unblessed reference at
>>
>> /usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
>> DBI.pm
>> line 128
>>    during global destruction.
>
> Does it still happen if you call $ses->flush(); before the script  
> exits?
>

Mark, (and others who helped me),

You were right about the above. When I first tried $ses->flush(); by  
mistake I didn't put it right before the script ended. The last  
statement in my script is, of course,

	# send the obligatory Content-Type and print the template
	print $cgi->header(-cookie=>$COOKIE), $T->output;


Putting $session->flush(); *after* the above statment clears the error.  
Fwiw, I am invoking

	new CGI::Session("driver:sqlite", $sid, {Handle=>$DBH})


Phew! Many thanks to you all for patiently holding my hand. I hope, if  
this helps making CGI-Session more robust, it was worth it. At the very  
least, I got rid of my error.

--
Puneet Kishor

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Ron S. <ro...@sa...>]

On Tue, 7 Mar 2006 07:55:41 -0600, Puneet Kishor wrote:

Hi Puneet

> I haven't tested/reproduced the above, but I have a few thoughts --
>
> One, the same error message could be triggered by two seemingly
> very different "outside" steps. In other words, in my case, the
> said message is triggered when I pass a db handle to create the
> session (the db and the table both exist as required), and in your
> case it happens when you try to create the db file itself.

Agreed.

> Two, it doesn't indicate a bug in SQLite. If anything, probably a
> bug in either CGI-Session or in DBD-SQLite.

I have had trouble with SQLite before (see archive for DBI mailing list), so=
 I 
was deeply suspicious of it before this thread started.

> Three, sort of building on two above -- many would not use SQLite
> in production, but for my purposes it is a capable database serving
> my production needs brilliantly. No other db comes even close in
> its portability and ease of management. SQLite is the core
> datasource in Mac OS X. If it is good enough for Apple, it is good
> enough for me.

OK.

> I am surprised, however, that CGI-Session-SQLite has not been
> exercised enough by the community to have brought this problem to
> light earlier. CGI-Session is great product, and a necessary one
> for building websites. It (or something as easy and portable as it)
> should be a part of core CGI, in my highly empirical view. I hope
> this problem can be corrected, and CGI-Session (and/or DBD-SQLite
> or any other dependent modules) made that much more robust as a
> result.

Well, we are all perhaps spread a bit thinly...

-- 
Cheers
Ron Savage, ro...@sa... on 8/03/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Cees H. <ce...@gm...>]

On 3/7/06, Puneet Kishor <pu...@ei...> wrote:
> > Are you explicitly disconnecting your DBH at some point in the code?
>
> Yes, at the end of the script.

Before doing anything else, comment out your line that disconnects the
database, and test again...

Cheers,

Cees

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

On Mar 7, 2006, at 8:52 AM, Cees Hek wrote:

> On 3/7/06, Puneet Kishor <pu...@ei...> wrote:
>> Yes, the same error as above is displayed even on adding flush() at 
>> the
>> end of the script.
>
> Are you explicitly disconnecting your DBH at some point in the code?

Yes, at the end of the script.

> Are you passing this DBH handle to any other modules?

Yes, to many other modules in between.

>
>> Hope that helps.
>
> What we really need is a self contained test script that shows the
> problem...  If people can't reproduce it properly, then it is very
> difficult to find or fix any problems.
>
> Write a simple script that we can run on the command line that will
> show the error.  I guarantee you if you accomplish that, then someone
> will find the problem very quickly (whether it is with SQLite,
> CGI::Session. DBI, or with your own code).


Thanks Cees. That is great advice, and I will try and do so. I will 
also look closely at my own application with the assumption that I am 
likely doing something screwy that can be corrected/simplified.

As soon as I have something concrete to report, I will do so.


--
Puneet Kishor

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Cees H. <ce...@gm...>]

On 3/7/06, Puneet Kishor <pu...@ei...> wrote:
> Yes, the same error as above is displayed even on adding flush() at the
> end of the script.

Are you explicitly disconnecting your DBH at some point in the code?=20
Are you passing this DBH handle to any other modules?

> Hope that helps.

What we really need is a self contained test script that shows the
problem...  If people can't reproduce it properly, then it is very
difficult to find or fix any problems.

Write a simple script that we can run on the command line that will
show the error.  I guarantee you if you accomplish that, then someone
will find the problem very quickly (whether it is with SQLite,
CGI::Session. DBI, or with your own code).

Cheers,

Cees

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

On Mar 7, 2006, at 8:29 AM, Mark Stosberg wrote:

> On Tue, Mar 07, 2006 at 07:45:57AM -0600, Puneet Kishor wrote:
>
>> well, if I change
>>
>> 	new CGI::Session("driver:sqlite", $sid, {Handle=>$DBH})
>>
>> to either of the following two choices
>>
>> 	new CGI::Session("driver:sqlite", $sid,
>> {Handle=>DBI->connect("dbi:SQLite:dbname=/path/to/my.db")})
>> 	new CGI::Session("driver:sqlite", $sid,
>> {DataSource=>"dbi:SQLite:dbname=/path/to/my.db"})
>>
>> The session value gets stored in the database alright, but I get the
>> following error
>>
>>>> (in cleanup) Can't call method "commit" on unblessed reference at
>>
>> /usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
>> DBI.pm
>> line 128
>>    during global destruction.
>
> Does it still happen if you call $ses->flush(); before the script  
> exits?
>

Yes, the same error as above is displayed even on adding flush() at the  
end of the script.

Hope that helps.

--
Puneet Kishor

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Mark S. <ma...@su...>]

On Tue, Mar 07, 2006 at 07:45:57AM -0600, Puneet Kishor wrote:
 
> well, if I change
> 
> 	new CGI::Session("driver:sqlite", $sid, {Handle=>$DBH})
> 
> to either of the following two choices
> 
> 	new CGI::Session("driver:sqlite", $sid, 
> {Handle=>DBI->connect("dbi:SQLite:dbname=/path/to/my.db")})
> 	new CGI::Session("driver:sqlite", $sid, 
> {DataSource=>"dbi:SQLite:dbname=/path/to/my.db"})
> 
> The session value gets stored in the database alright, but I get the 
> following error
> 
> >> (in cleanup) Can't call method "commit" on unblessed reference at
>    
> /usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/DBI.pm 
> line 128
>    during global destruction.

Does it still happen if you call $ses->flush(); before the script exits? 

This sounds like a different, known issue with our use of DESTROY:

	http://rt.cpan.org/Public/Bug/Display.html?id=17541

My most recent thinking on this is that we should add a "auto_flush"
option, which would currently default to false.

It would prevent the activity at DESTORY time, with people making
explicit calls to flush() instead.  

We'd have a big warning in the ChangeLog that people need to change the
call to new() if they want to preserve the old behavior. 

Thoughts on this? Sherzod? 

It seems like the auto-flushing code continues to cause problems and
should really not be recommended or turned on by default. 

	Mark

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

On Mar 7, 2006, at 1:30 AM, Ron Savage wrote:

> On Mon, 06 Mar 2006 15:56:00 -0600, Puneet Kishor wrote:
>
> Hi Puneet
>
>> [] [Mon Mar  6 15:44:04 2006] index.cgi: DBD::SQLite::db prepare
>> failed: no such table: sessions(1) at dbdimp.c line 269 at
>> C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during global
>> destruction.\r, referer: http://localhost/punkish/index.cgi
>
> I tested SQLite with my module CGI::Application::Demo, which is 
> designed to
> probe strange environments, by patching the config file 
> cgi-app-four.conf.
>
> And I get the same error!
>
> It's caused by a bug in SQLite, which emits this error when you create 
> the
> database file (as in dsn=dbi:SQLite:dbname=/temp/cgi-app-demo.db) for 
> the first
> time, and then try a command such as
>  	eval{$$self{'_dbh'} -> do("drop table $table_name")};
> The program I was running to prove this (under Win2K) is create.pl, 
> which ships
> with CGI::Application::Demo
>
> The error msg is emitted despite the eval.
>
> By running create.pl repeatedly, with and without first deleting
> /temp/cgi-app-demo.db, proves that if the database file is present, 
> SQLite does
> not emit this msg, but if the database file is absent, so that running 
> the
> program must create it, then the error msg is emitted by the drop table
> statement. In your case, some other stmt causes the error, but it's 
> the same
> problem. I believe that the problem arises with the very first SQL 
> command
> executed after the database file is created.
>
> I'll report it to the author of SQLite.
>
> Warning: Personally, I would never use SQLite in production, anyway.
>

Greetings Ron,

I haven't tested/reproduced the above, but I have a few thoughts --

One, the same error message could be triggered by two seemingly very 
different "outside" steps. In other words, in my case, the said message 
is triggered when I pass a db handle to create the session (the db and 
the table both exist as required), and in your case it happens when you 
try to create the db file itself.

Two, it doesn't indicate a bug in SQLite. If anything, probably a bug 
in either CGI-Session or in DBD-SQLite.

Three, sort of building on two above -- many would not use SQLite in 
production, but for my purposes it is a capable database serving my 
production needs brilliantly. No other db comes even close in its 
portability and ease of management. SQLite is the core datasource in 
Mac OS X. If it is good enough for Apple, it is good enough for me.

I am surprised, however, that CGI-Session-SQLite has not been exercised 
enough by the community to have brought this problem to light earlier. 
CGI-Session is great product, and a necessary one for building 
websites. It (or something as easy and portable as it) should be a part 
of core CGI, in my highly empirical view. I hope this problem can be 
corrected, and CGI-Session (and/or DBD-SQLite or any other dependent 
modules) made that much more robust as a result.


--
Puneet Kishor

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

On Mar 7, 2006, at 1:39 AM, Sherzod Ruzmetov wrote:

> That's the start,
>
> Now, instead of passing a database handle to CGI::Session->new(), why
> don't you try to initialize it with a full datasource description?
>

well, if I change

	new CGI::Session("driver:sqlite", $sid, {Handle=>$DBH})

to either of the following two choices

	new CGI::Session("driver:sqlite", $sid, 
{Handle=>DBI->connect("dbi:SQLite:dbname=/path/to/my.db")})
	new CGI::Session("driver:sqlite", $sid, 
{DataSource=>"dbi:SQLite:dbname=/path/to/my.db"})

The session value gets stored in the database alright, but I get the 
following error

 >> (in cleanup) Can't call method "commit" on unblessed reference at
    
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/DBI.pm 
line 128
    during global destruction.



>
>> -----Original Message-----
>> From: cgi...@li...
>> [mailto:cgi...@li...] On
>> Behalf Of Puneet Kishor
>> Sent: Monday, March 06, 2006 10:52 PM
>> To: List - CGI-Session
>> Cc: ro...@sa...; Mark Stosberg
>> Subject: Re: [Cgi-session-user] Trouble with C::S::SQLite
>>
>>
>> Ok, making progress.
>>
>> I modified the CGI/Session/Driver/sqlite.pm like so --
>>
>> sub store {
>>      my $self = shift;
>>      my ($sid, $datastr) = @_;
>>      return $self->set_error("store(): usage error") unless $sid &&
>> $datastr;
>>
>>      #my $dbh = $self->{Handle};
>> 	my $dbh =
>> DBI->connect("dbi:SQLite:dbname=/path/to/my.db") or die "Db
>> connect failed: $DBI::errstr";
>>      my $sth = $dbh->prepare("SELECT id FROM " .
>> $self->table_name . "
>> WHERE id=?");
>>
>> And it works just fine. My session value is stored in the sessions
>> table, and reused properly. So, the error is in the way $dbh is being
>> passed. I am using the following syntax in my calling script --
>>
>>      new CGI::Session("driver:sqlite", $sid, {Handle=>$dbh})
>>
>> and that is not working... the db handle is getting messed up. Any
>> ideas from this little experiment, anyone?
>>
>>
>> On Mar 6, 2006, at 9:30 PM, Ron Savage wrote:
>>
>>> On Mon, 6 Mar 2006 21:18:09 -0600, Puneet Kishor wrote:
>>>
>>> Hi Puneet
>>>
>>>> 34= sub store {
>>>> 35=     my $self = shift;
>>>> 36=     my ($sid, $datastr) = @_;
>>>> 37=     return $self->set_error("store(): usage error") unless $sid
>>>> && $datastr;
>>>> 38=
>>>> 39=     my $dbh = $self->{Handle}; 40=
>>>> 41=     my $sth = $dbh->prepare("SELECT id FROM " . $self-
>>>>> table_name . " WHERE id=?");
>>>
>>> At this point I would write the value returned by $self ->
>>> table_name() to the web server's log, or to a disk file. That will
>>> tell you /exactly/ what the program thinks the table's name is.
>>>
>>>> 42=     unless ( defined $sth ) {
>>>> 43=         return $self->set_error( "store(): \$sth->prepare
>>>> failed with message " . $dbh->errstr );
>>>> 44=     } .


--
Puneet Kishor

RE: [Cgi-session-user] Trouble with C::S::SQLite

[Sherzod R. <she...@ha...>]

That's the start,

Now, instead of passing a database handle to CGI::Session->new(), why
don't you try to initialize it with a full datasource description?

See if that makes any difference.


> -----Original Message-----
> From: cgi...@li... 
> [mailto:cgi...@li...] On 
> Behalf Of Puneet Kishor
> Sent: Monday, March 06, 2006 10:52 PM
> To: List - CGI-Session
> Cc: ro...@sa...; Mark Stosberg
> Subject: Re: [Cgi-session-user] Trouble with C::S::SQLite
> 
> 
> Ok, making progress.
> 
> I modified the CGI/Session/Driver/sqlite.pm like so --
> 
> sub store {
>      my $self = shift;
>      my ($sid, $datastr) = @_;
>      return $self->set_error("store(): usage error") unless $sid && 
> $datastr;
> 
>      #my $dbh = $self->{Handle};
> 	my $dbh = 
> DBI->connect("dbi:SQLite:dbname=/path/to/my.db") or die "Db 
> connect failed: $DBI::errstr";
>      my $sth = $dbh->prepare("SELECT id FROM " . 
> $self->table_name . " 
> WHERE id=?");
> 
> And it works just fine. My session value is stored in the sessions 
> table, and reused properly. So, the error is in the way $dbh is being 
> passed. I am using the following syntax in my calling script --
> 
>      new CGI::Session("driver:sqlite", $sid, {Handle=>$dbh})
> 
> and that is not working... the db handle is getting messed up. Any 
> ideas from this little experiment, anyone?
> 
> 
> On Mar 6, 2006, at 9:30 PM, Ron Savage wrote:
> 
> > On Mon, 6 Mar 2006 21:18:09 -0600, Puneet Kishor wrote:
> >
> > Hi Puneet
> >
> >> 34= sub store {
> >> 35=     my $self = shift;
> >> 36=     my ($sid, $datastr) = @_;
> >> 37=     return $self->set_error("store(): usage error") unless $sid
> >> && $datastr;
> >> 38=
> >> 39=     my $dbh = $self->{Handle}; 40=
> >> 41=     my $sth = $dbh->prepare("SELECT id FROM " . $self-
> >>> table_name . " WHERE id=?");
> >
> > At this point I would write the value returned by $self -> 
> > table_name() to the web server's log, or to a disk file. That will 
> > tell you /exactly/ what the program thinks the table's name is.
> >
> >> 42=     unless ( defined $sth ) {
> >> 43=         return $self->set_error( "store(): \$sth->prepare
> >> failed with message " . $dbh->errstr );
> >> 44=     } .
> >
> 
> 
> --
> Puneet Kishor
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking 
> scripting language that extends applications into web and 
> mobile media. Attend the live webcast and join the prime 
> developer group breaking into this new coding territory! 
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Cgi-session-user mailing list Cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgi-session-user

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Ron S. <ro...@sa...>]

On Mon, 06 Mar 2006 15:56:00 -0600, Puneet Kishor wrote:

Hi Puneet

> [] [Mon Mar  6 15:44:04 2006] index.cgi: DBD::SQLite::db prepare
> failed: no such table: sessions(1) at dbdimp.c line 269 at
> C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during global
> destruction.\r, referer: http://localhost/punkish/index.cgi

I tested SQLite with my module CGI::Application::Demo, which is designed to=
 
probe strange environments, by patching the config file cgi-app-four.conf.

And I get the same error!

It's caused by a bug in SQLite, which emits this error when you create the 
database file (as in dsn=3Ddbi:SQLite:dbname=3D/temp/cgi-app-demo.db) for the=
 first 
time, and then try a command such as
 =09eval{$$self{'_dbh'} -> do("drop table $table_name")};
The program I was running to prove this (under Win2K) is create.pl, which=
 ships 
with CGI::Application::Demo

The error msg is emitted despite the eval.

By running create.pl repeatedly, with and without first deleting 
/temp/cgi-app-demo.db, proves that if the database file is present, SQLite=
 does 
not emit this msg, but if the database file is absent, so that running the 
program must create it, then the error msg is emitted by the drop table 
statement. In your case, some other stmt causes the error, but it's the same=
 
problem. I believe that the problem arises with the very first SQL command 
executed after the database file is created.

I'll report it to the author of SQLite.

Warning: Personally, I would never use SQLite in production, anyway.
-- 
Cheers
Ron Savage, ro...@sa... on 7/03/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

Ok, making progress.

I modified the CGI/Session/Driver/sqlite.pm like so --

sub store {
     my $self = shift;
     my ($sid, $datastr) = @_;
     return $self->set_error("store(): usage error") unless $sid && 
$datastr;

     #my $dbh = $self->{Handle};
	my $dbh = DBI->connect("dbi:SQLite:dbname=/path/to/my.db") or die "Db 
connect failed: $DBI::errstr";
     my $sth = $dbh->prepare("SELECT id FROM " . $self->table_name . " 
WHERE id=?");

And it works just fine. My session value is stored in the sessions 
table, and reused properly. So, the error is in the way $dbh is being 
passed. I am using the following syntax in my calling script --

     new CGI::Session("driver:sqlite", $sid, {Handle=>$dbh})

and that is not working... the db handle is getting messed up. Any 
ideas from this little experiment, anyone?


On Mar 6, 2006, at 9:30 PM, Ron Savage wrote:

> On Mon, 6 Mar 2006 21:18:09 -0600, Puneet Kishor wrote:
>
> Hi Puneet
>
>> 34= sub store {
>> 35=     my $self = shift;
>> 36=     my ($sid, $datastr) = @_;
>> 37=     return $self->set_error("store(): usage error") unless $sid
>> && $datastr;
>> 38=
>> 39=     my $dbh = $self->{Handle}; 40=
>> 41=     my $sth = $dbh->prepare("SELECT id FROM " . $self-
>>> table_name . " WHERE id=?");
>
> At this point I would write the value returned by $self -> table_name()
> to the web server's log, or to a disk file. That will tell you 
> /exactly/ what
> the program thinks the table's name is.
>
>> 42=     unless ( defined $sth ) {
>> 43=         return $self->set_error( "store(): \$sth->prepare
>> failed with message " . $dbh->errstr );
>> 44=     } .
>


--
Puneet Kishor

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Ron S. <ro...@sa...>]

On Mon, 6 Mar 2006 21:18:09 -0600, Puneet Kishor wrote:

Hi Puneet

> 34=3D sub store {
> 35=3D     my $self =3D shift;
> 36=3D     my ($sid, $datastr) =3D @_;
> 37=3D     return $self->set_error("store(): usage error") unless $sid
> && $datastr; 
> 38=3D
> 39=3D     my $dbh =3D $self->{Handle}; 40=3D
> 41=3D     my $sth =3D $dbh->prepare("SELECT id FROM " . $self-
> >table_name . " WHERE id=3D?");

At this point I would write the value returned by $self -> table_name()
to the web server's log, or to a disk file. That will tell you /exactly/=
 what 
the program thinks the table's name is.

> 42=3D     unless ( defined $sth ) {
> 43=3D         return $self->set_error( "store(): \$sth->prepare
> failed with message " . $dbh->errstr );
> 44=3D     } .
-- 
Cheers
Ron Savage, ro...@sa... on 7/03/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

On Mar 6, 2006, at 9:01 PM, Ron Savage wrote:

> On Mon, 6 Mar 2006 18:28:11 -0600, Puneet Kishor wrote:
>
> Hi Puneet
>
>> [Mon Mar  6 18:23:27 2006] index.cgi: DBD::SQLite::db prepare
>> failed: no such table: sessions(1) at dbdimp.c line 269 at
>
> The fact that the table is called sessions(1) and not sessions is the  
> clue to
> follow first. Check the SQL used or generated.
>

unfortunately that is no clue at all, or at least that I can  
comprehend. The offending line is in: CGI/Session/Driver/sqlite.pm line  
41

34= sub store {
35=     my $self = shift;
36=     my ($sid, $datastr) = @_;
37=     return $self->set_error("store(): usage error") unless $sid &&  
$datastr;
38=
39=     my $dbh = $self->{Handle};
40=
41=     my $sth = $dbh->prepare("SELECT id FROM " . $self->table_name .  
" WHERE id=?");
42=     unless ( defined $sth ) {
43=         return $self->set_error( "store(): \$sth->prepare failed  
with message " . $dbh->errstr );
44=     }
..

as is evident from above, the table name is being passed to store() as  
$self->table_name. I believe the (1) in "sessions(1)" is just how the  
error trace outputs (I really don't understand these things very well).  
There is more clue in the DBI trace

 >>     -> execute for DBD::SQLite::st (DBI::st=HASH(0x9818f0)~0x990bec  
'7c98910b13164f53bc2df9024783e5f2') thr#800200
 >> sqlite trace: bind into 0x990c34: 1 =>  
7c98910b13164f53bc2df9024783e5f2 (0) pos 0
 >>  at dbdimp.c line 443
 >> sqlite trace: Execute returned 1 cols
 >>  at dbdimp.c line 391
 >>     <- execute= '0E0' at DBI.pm line 71 via  
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session.pm line 664
 >>     -> fetchrow_array for DBD::SQLite::st  
(DBI::st=HASH(0x9818f0)~0x990bec) thr#800200
 >>     <- fetchrow_array= ( ) [0 items] row-1 at DBI.pm line 73 via  
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/
        Session.pm line 664
 >> [Mon Mar  6 18:32:33 2006] index.cgi: DBD::SQLite::db prepare  
failed: no such table: sessions(1) at dbdimp.c line 269 at />>  
usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
sqlite.pm line 41 during global destruction.

As is evident from above, the "SELECT id FROM sessions WHERE id=?"  
statement is executed with the session id  
'7c98910b13164f53bc2df9024783e5f2' passed for querying. I even get back  
one col as is evident from

sqlite trace: Execute returned 1 cols

and 0 items

 >> fetchrow_array= ( ) [0 items] row-1

because there is no value stored yet. Everything fine thus far. And  
then, failure "during global destruction"!

What puzzles me is that this couldn't possibly be something new. I am  
prone to believe that I am doing something wrong... surely, others must  
be using SQLite as the sessions store, and CGI-Session has been around  
for a while. I couldn't possibly have discovered a show-stopper bug.



--
Puneet Kishor

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Ron S. <ro...@sa...>]

On Mon, 6 Mar 2006 18:28:11 -0600, Puneet Kishor wrote:

Hi Puneet

> [Mon Mar  6 18:23:27 2006] index.cgi: DBD::SQLite::db prepare
> failed: no such table: sessions(1) at dbdimp.c line 269 at

The fact that the table is called sessions(1) and not sessions is the clue=
 to
follow first. Check the SQL used or generated.

-- 
Cheers
Ron Savage, ro...@sa... on 7/03/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Mark S. <ma...@su...>]

On Mon, Mar 06, 2006 at 06:28:11PM -0600, Puneet Kishor wrote:
> 
> Rats... exactly the same message as below on Mac OS X 10.3.9 with  
> AciveState Perl 5.8.7 and CGI::Session 4.05 downloaded from CPAN using  
> DBD::SQLite 1.11 (first instance was on a WinXP box). Here is the  
> message --
> 
> [Mon Mar  6 18:23:27 2006] index.cgi: DBD::SQLite::db prepare failed:  
> no such table: sessions(1) at dbdimp.c line 269 at  
> /usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
> sqlite.pm line 41 during global destruction.
> [Mon Mar  6 18:23:27 2006] index.cgi: 	(in cleanup) DBD::SQLite::db  
> prepare failed: no such table: sessions(1) at dbdimp.c line 269 at  
> /usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
> sqlite.pm line 41 during global destruction.
> [Mon Mar  6 18:23:44 2006] index.cgi: DBD::SQLite::db prepare failed:  
> no such table: sessions(1) at dbdimp.c line 269 at  
> /usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
> sqlite.pm line 41 during global destruction.
> [Mon Mar  6 18:23:44 2006] index.cgi: 	(in cleanup) DBD::SQLite::db  
> prepare failed: no such table: sessions(1) at dbdimp.c line 269 at  
> /usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
> sqlite.pm line 41 during global destruction.
> 
> This is very frustrating, and I am at my wits end, so any help/guidance  
> from anyone would be very welcome.

Puneet.

Pretend your code is OK and that this a bug in a third party module,
like CGI::Session or DBD::SQLite. 

Write a simple test using Test::More, etc. If it fails, submit a bug
report. If it passes, there's something about the context of your
application making it fail.  

If it passes, keep making changes to the test to make it more like your
application until it fails. The last thing you changed before it starts
to fail must be the bug!

Finally, consider using another driver as a pragmatic solution to keep
the big picture of your project moving. You'll only need to change one
line of code to switch back to the SQLite driver later! 

	Mark

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

Rats... exactly the same message as below on Mac OS X 10.3.9 with  
AciveState Perl 5.8.7 and CGI::Session 4.05 downloaded from CPAN using  
DBD::SQLite 1.11 (first instance was on a WinXP box). Here is the  
message --

[Mon Mar  6 18:23:27 2006] index.cgi: DBD::SQLite::db prepare failed:  
no such table: sessions(1) at dbdimp.c line 269 at  
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
sqlite.pm line 41 during global destruction.
[Mon Mar  6 18:23:27 2006] index.cgi: 	(in cleanup) DBD::SQLite::db  
prepare failed: no such table: sessions(1) at dbdimp.c line 269 at  
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
sqlite.pm line 41 during global destruction.
[Mon Mar  6 18:23:44 2006] index.cgi: DBD::SQLite::db prepare failed:  
no such table: sessions(1) at dbdimp.c line 269 at  
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
sqlite.pm line 41 during global destruction.
[Mon Mar  6 18:23:44 2006] index.cgi: 	(in cleanup) DBD::SQLite::db  
prepare failed: no such table: sessions(1) at dbdimp.c line 269 at  
/usr/local/ActivePerl-5.8/lib/site_perl/5.8.7/CGI/Session/Driver/ 
sqlite.pm line 41 during global destruction.

This is very frustrating, and I am at my wits end, so any help/guidance  
from anyone would be very welcome.

Many thanks.


On Mar 6, 2006, at 2:10 PM, Puneet Kishor wrote:

> I upgraded from C::S 3.95 to 4.03 with the hopes of storing the session
> info in SQLite. Have run into a problem that has occupied me for a
> couple of days now. I get the following message that I can't go past --
>
> [Mon Mar 06 13:20:24 2006] [error] index.cgi: DBD::SQLite::db prepare
> failed: no such table: sessions(1) at dbdimp.c line 269 at
> C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during global
> destruction.\r, referer: ..
>
> [Mon Mar 06 13:20:24 2006] [error] index.cgi: \t(in cleanup)
> DBD::SQLite::db prepare failed: no such table: sessions(1) at dbdimp.c
> line 269 at C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43  
> during
> global destruction.\r, referer: ..
>
> Some background -- using ActiveState Perl 5.8.7. Got the 4.03 ppd from
> Randy Kobes website (I can't find a 4.05 ppd anywhere). I am using
> DBD::SQLite 1.11 (latest version). Other than the problem with the
> session, DBD::SQLite works just fine. I have the requisite table
> "sessions" in my database with the requisite schema.
>
> sqlite> .schema sessions
> CREATE TABLE 'sessions' (
>         id CHAR(32) NOT NULL PRIMARY KEY,
>         a_session TEXT NOT NULL
>     );
> sqlite>
>
>
> Many thanks in advance,


--
Puneet Kishor

[Cgi-session-user] Re: CGI::Session YAML status ?

[Tyler M. <ty...@yi...>]

Mark Stosberg <ma...@su...> wrote:
> Do you have everything you need to integrate the YAML driver stuff into
> CGI::Session?  I can roll out a new release when that's ready.

	I did a bit more on this last night but haven't *quite* completed it
yet. There'll be another update to Test/Default.pm soon, then hopefully I
can just drop YAML in and it'll work. :)

	I have run into a bit of a roadblock with JSON support though,
JSON::Syck is buggy in a way that's interfering with an application I'm
developing; you can see the bug here:

	http://rt.cpan.org/Ticket/Display.html?id=18021

	If I'm feeling brave I might make a detour to submit a patch for
that, but either way, I hope to have my CGI::Session changes checked in
within the next few days. Sorry for the delay. :)

		- Tyler

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

Mark Stosberg wrote:
..
> 
> You could try DBI->trace(3) to turn on very verbose database debugging.
> 


Thanks for you help Mark. I turned on the trace, and got the following
relevant lines in the error log (I've taken out the datetime stamp
between the [] for brevity). I hope this sheds some light to you (or
anyone else)... it has me completely stumped, and has brought my work to
a standstill :-(. Still, thanks a ton for your assistance thus far.



[]     DBI 1.48-ithread default trace level set to 0x0/3 (pid 4832)\r,
referer: http://localhost/punkish/index.cgi
[]     -> STORE for DBD::SQLite::db (DBI::db=HASH(0x1e0a488)~INNER
'sqlite_handle_binary_nulls' 1) thr#22434c\r, referer:
http://localhost/punkish/index.cgi
[]     STORE DBI::db=HASH(0x1e0a488) 'sqlite_handle_binary_nulls' =>
1\r, referer: http://localhost/punkish/index.cgi
[] $h->{'sqlite_handle_binary_nulls'}=1 ignored for invalid
driver-specific attribute\r, referer: http://localhost/punkish/index.cgi
[]     <- STORE= '' at sqlite.pm line 18 via
C:/Perl/site/lib/CGI/Session/Driver.pm line 27\r, referer:
http://localhost/punkish/index.cgi
[]     -> prepare_cached in DBD::_::db for DBD::SQLite::db
(DBI::db=HASH(0x1e0110c)~0x1e0a488 'SELECT a_session FROM sessions WHERE
id=?' undef 3) thr#22434c\r, referer: http://localhost/punkish/index.cgi
[] 1   -> FETCH for DBD::SQLite::db (DBI::db=HASH(0x1e0a488)~INNER
'CachedKids') thr#22434c\r, referer: http://localhost/punkish/index.cgi
[]     .. FETCH DBI::db=HASH(0x1e0a488) 'CachedKids' = undef\r, referer:
http://localhost/punkish/index.cgi
[] 1   <- FETCH= undef at DBI.pm line 1606 via
C:/Perl/site/lib/CGI/Session/Driver/DBI.pm line 61\r, referer:
http://localhost/punkish/index.cgi
[] 1   -> STORE for DBD::SQLite::db (DBI::db=HASH(0x1e0a488)~INNER
'CachedKids' HASH(0x1e27124)) thr#22434c\r, referer:
http://localhost/punkish/index.cgi
[]     STORE DBI::db=HASH(0x1e0a488) 'CachedKids' => HASH(0x1e27124)\r,
referer: http://localhost/punkish/index.cgi
[] 1   <- STORE= 1 at DBI.pm line 1607 via
C:/Perl/site/lib/CGI/Session/Driver/DBI.pm line 61\r, referer:
http://localhost/punkish/index.cgi
[] 1   -> prepare for DBD::SQLite::db (DBI::db=HASH(0x1e0a488)~INNER
'SELECT a_session FROM sessions WHERE id=?' undef) thr#22434c\r,
referer: http://localhost/punkish/index.cgi
[]     New DBI::st (for DBD::SQLite::st, parent=DBI::db=HASH(0x1e0a488),
id=)\r, referer: http://localhost/punkish/index.cgi
[]
dbih_setup_handle(DBI::st=HASH(0x1e0a5a8)=>DBI::st=HASH(0x1e27154),
DBD::SQLite::st, 1e0a5b4, Null!)\r, referer:
http://localhost/punkish/index.cgi
[]     dbih_make_com(DBI::db=HASH(0x1e0a488), 1d53484, DBD::SQLite::st,
124, 0) thr#22434c\r, referer: http://localhost/punkish/index.cgi
[] sqlite trace: prepare statement: SELECT a_session FROM sessions WHERE
id=?\r, referer: http://localhost/punkish/index.cgi
[] 1   <- prepare= DBI::st=HASH(0x1e0a5a8) at DBI.pm line 1618 via
C:/Perl/site/lib/CGI/Session/Driver/DBI.pm line 61\r, referer:
http://localhost/punkish/index.cgi
[]     <- prepare_cached= DBI::st=HASH(0x1e0a5a8) at DBI.pm line 61 via
C:/Perl/site/lib/CGI/Session.pm line 662\r, referer:
http://localhost/punkish/index.cgi
[]     -> execute for DBD::SQLite::st (DBI::st=HASH(0x1e0a5a8)~0x1e27154
'009b29d8d7db6a9ae0239dcbd7c61c3c') thr#22434c\r, referer:
http://localhost/punkish/index.cgi
[] sqlite trace: bind into 0x1e2719c: 1 =>
009b29d8d7db6a9ae0239dcbd7c61c3c (0) pos 0\r, referer:
http://localhost/punkish/index.cgi
[] \r, referer: http://localhost/punkish/index.cgi
[] sqlite trace: Execute returned 1 cols\r, referer:
http://localhost/punkish/index.cgi
[] \r, referer: http://localhost/punkish/index.cgi
[]     <- execute= '0E0' at DBI.pm line 65 via
C:/Perl/site/lib/CGI/Session.pm line 662\r, referer:
http://localhost/punkish/index.cgi
[]     -> fetchrow_array for DBD::SQLite::st
(DBI::st=HASH(0x1e0a5a8)~0x1e27154) thr#22434c\r, referer:
http://localhost/punkish/index.cgi
[]     <- fetchrow_array= ( ) [0 items] row-1 at DBI.pm line 67 via
C:/Perl/site/lib/CGI/Session.pm line 662\r, referer:
http://localhost/punkish/index.cgi
[] [Mon Mar  6 15:44:04 2006] index.cgi: DBD::SQLite::db prepare failed:
no such table: sessions(1) at dbdimp.c line 269 at
C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during global
destruction.\r, referer: http://localhost/punkish/index.cgi
[] [Mon Mar  6 15:44:04 2006] index.cgi: \t(in cleanup) DBD::SQLite::db
prepare failed: no such table: sessions(1) at dbdimp.c line 269 at
C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during global
destruction.\r, referer: http://localhost/punkish/index.cgi

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Mark S. <ma...@su...>]

On Mon, Mar 06, 2006 at 03:22:29PM -0600, Puneet Kishor wrote:
 
> Ok, I will look at that, but isn't
> 
> new CGI::Session("driver:sqlite", $sid, {Handle=>$DBH})
> 
> the correct syntax, as noted in the documentation?

Yes. 

You could try DBI->trace(3) to turn on very verbose database debugging.

Beyond these suggestions, I'm not sure I can be of further help-- I
don't use the SQLite driver myself.

One option you have is try adding another test to the test suite to test
for what appears to be the "bug" you are experiencing. If the test
passes, there must be some difference between the context of our test
suite and your application.

	Mark

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

Mark Stosberg wrote:
> On Mon, Mar 06, 2006 at 03:01:06PM -0600, Puneet Kishor wrote:
>> Mark, any suggestions how/what debugging to turn on besides the usual
>> diagnostics and -w? Actually, I also ran the script through the debugger
>> but wasn't any wiser. I should have added my code snippet in the above
>> email in the first place... this is what I am doing (simplified just a
>> tad bit) --
>>
>> $DBH = DBI->connect("dbi:SQLite:dbname=/path/to/my.db") or die;
> 
> Using this $DBH handle, you can access the session table directly,
> outside of CGI::Session?
> 
>   my @row = $DBH->selectrow_array("SELECT * FROM sessions");
>   use Data::Dumper;
>   warn Dumper (\@row);
> 


that works just fine (well, a variation of the above). Here is what I did...

inserted a couple of rows into "sessions"

  sqlite> .schema sessions
  CREATE TABLE 'sessions' (
        id CHAR(32) NOT NULL PRIMARY KEY,
        a_session TEXT NOT NULL
    );
  sqlite> select * from sessions;
  sqlite> insert into sessions (id, a_session) values (1, "foo");
  sqlite> insert into sessions (id, a_session) values (2, "bar");
  sqlite> select * from sessions;
  1|foo
  2|bar
  sqlite>


Then, in my script, after the session statements...

  my @row = $DBH->selectrow_array("SELECT * FROM sessions");
  ..
  $T->param( TMP => join(",", @row), );


And, in my template <TMPL_VAR TMP>. In my web page I got...

  1,foo

and in my error log I got the same session error as above.


> 
> Also, you may want to 'grep' the test suite shipped with CGI::Session to
> see the syntax that we are using with SQLite that is known to work.

Ok, I will look at that, but isn't

new CGI::Session("driver:sqlite", $sid, {Handle=>$DBH})

the correct syntax, as noted in the documentation?

Thanks.

--
Puneet Kishor

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Mark S. <ma...@su...>]

On Mon, Mar 06, 2006 at 03:01:06PM -0600, Puneet Kishor wrote:
> 
> Mark, any suggestions how/what debugging to turn on besides the usual
> diagnostics and -w? Actually, I also ran the script through the debugger
> but wasn't any wiser. I should have added my code snippet in the above
> email in the first place... this is what I am doing (simplified just a
> tad bit) --
> 
> $DBH = DBI->connect("dbi:SQLite:dbname=/path/to/my.db") or die;

Using this $DBH handle, you can access the session table directly,
outside of CGI::Session?

  my @row = $DBH->selectrow_array("SELECT * FROM sessions");
  use Data::Dumper;
  warn Dumper (\@row);

That should return a single row from the session table for you.
If that doesn't work, your problem is more fundamental, not related to
CGI::Session. 

Also, you may want to 'grep' the test suite shipped with CGI::Session to
see the syntax that we are using with SQLite that is known to work.

	Mark

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Puneet K. <pu...@ei...>]

Mark Stosberg wrote:
> On Mon, Mar 06, 2006 at 02:10:09PM -0600, Puneet Kishor wrote:
>> I upgraded from C::S 3.95 to 4.03 with the hopes of storing the session
>> info in SQLite. Have run into a problem that has occupied me for a
>> couple of days now. I get the following message that I can't go past --
>>
>> [Mon Mar 06 13:20:24 2006] [error] index.cgi: DBD::SQLite::db prepare
>> failed: no such table: sessions(1) at dbdimp.c line 269 at
>> C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during global
>> destruction.\r, referer: ..
>>
>> [Mon Mar 06 13:20:24 2006] [error] index.cgi: \t(in cleanup)
>> DBD::SQLite::db prepare failed: no such table: sessions(1) at dbdimp.c
>> line 269 at C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during
>> global destruction.\r, referer: ..
> 
> Puneet,
> 
> Can you turn on some debugging to insure that the path to the SQLite
> database is the same one your code is following to get there?
> 
> Maybe the code is looking in the wrong place for it.
> 


Mark, any suggestions how/what debugging to turn on besides the usual
diagnostics and -w? Actually, I also ran the script through the debugger
but wasn't any wiser. I should have added my code snippet in the above
email in the first place... this is what I am doing (simplified just a
tad bit) --

$DBH = DBI->connect("dbi:SQLite:dbname=/path/to/my.db") or die;

my $sid  = $cgi->cookie('CGISESSID') ||
           $cgi->param('CGISESSID')  ||
           undef;

$SESSION = new CGI::Session("driver:sqlite", $sid, {Handle=>$DBH}) or
           die CGI::Session->errstr;

$COOKIE  = $cgi->cookie(CGISESSID => $SESSION->id);

# followed by a bunch of code to get data from $DBH...
# all that works fine, web page gets rendered fine,
# but the session doesn't stick, and the above mentioned
# error shows up in the log

I have also tried a few variations -- I tried
{Datasource=>/path/to/sessions.sqlt} option, and I get exactly the same
error message (created a sessions.sqlt with the requisite sessions table
inside of it).

Besides CGI::Session, I am using HTML::Template and CGI::Simple.

Hope this helps you (and others) help me.

Many thanks,

--
Puneet Kishor

Re: [Cgi-session-user] Trouble with C::S::SQLite

[Mark S. <ma...@su...>]

On Mon, Mar 06, 2006 at 02:10:09PM -0600, Puneet Kishor wrote:
> I upgraded from C::S 3.95 to 4.03 with the hopes of storing the session
> info in SQLite. Have run into a problem that has occupied me for a
> couple of days now. I get the following message that I can't go past --
> 
> [Mon Mar 06 13:20:24 2006] [error] index.cgi: DBD::SQLite::db prepare
> failed: no such table: sessions(1) at dbdimp.c line 269 at
> C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during global
> destruction.\r, referer: ..
> 
> [Mon Mar 06 13:20:24 2006] [error] index.cgi: \t(in cleanup)
> DBD::SQLite::db prepare failed: no such table: sessions(1) at dbdimp.c
> line 269 at C:/Perl/site/lib/CGI/Session/Driver/sqlite.pm line 43 during
> global destruction.\r, referer: ..

Puneet,

Can you turn on some debugging to insure that the path to the SQLite
database is the same one your code is following to get there?

Maybe the code is looking in the wrong place for it.

	Mark