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

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

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

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] ANN: CGI::Session 4.04 released

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

I've now sent CGI::Session 4.04 to CPAN. Below are the changes since the
last release. A special thanks goes to Matt LeBlanc, who provided most
of the commits for this release. 

If you are interested in helping out as well, please get in touch. We
will give out access to the SVN server fairly easily. As a reminder, 
there are still a number of open issues we would like to see addressed.
The bug tracker is a great starting point:
http://rt.cpan.org/Public/Dist/Display.html?Name=CGI-Session

    * NEW: File driver now has option to disable flock (for those running
      Win 9x, VMS, MacPerl, VOS and RISC OS). (Matt LeBlanc)
    * FIX: If DBI driver wass initialized using 'Handle', Driver::DBI::init()
      returned false, and Driver::new() thought init faild and kept returning
      undef. The problem was fixed by making sure Driver::DBI::init() returned
      true. (Sherzod)
    * Added .*cgisess.* to disclude cgisess.db, cgisess.id, and any session
      files created in the t directory. (Matt LeBlanc)

    * FIX: File driver now respects $CGI::Session::File::FileName for 3.9x
      compatibility. (Matt LeBlanc)
    * FIX: Default serializer now properly handles data structures that appear
      more than once in the serialized data structure (before it'd result in data
      structures that were equivalent but did not have the same address). (Matt LeBlanc)
    * FIX: File driver now localizes the filehandle to avoid any possibility
      of extended locking in persistent environments (Matt LeBlanc)
    * FIX: File driver now locks the file when retrieving the session data (Matt LeBlanc)
    * NEW: DBI Drivers now support a lazy loaded database handle. This is useful with the
      CGI::Application plugin system. If the session is never used, the database handle may not
      not need to be created. The syntax is to use a code ref:
        Handle => sub {DBI->connect} (Mark Stosberg)

    Finally, be aware that since 4.0 some people have reported problems with
    the auto-flushing code. There may be an unresolved. You always  call
    flush() to be safe. Input or code contributions for the issue are
    appreciated. Some related tickets include:

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

Thanks!

	Mark

Re: [Cgi-session-user] Progress with CGI::Session::Serialize::yaml

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

On Sat, Feb 25, 2006 at 01:52:20PM -0800, Tyler MacDonald wrote:
> 
> 	OK, so being that all of the drivers have the exact same interface,
> and they're at least forwards-compatible (YAML can read JSON), I'd suggest
> that we have one serializer provide all of them. With the current API this
> equates to something like:
> 
> 	my $session = CGI::Session->new(undef, "s=yaml");
> 	$session->_serializer->use('JSON::Syck');
> 
> 	or
> 
> 	local $CGI::Session::Serializer::yaml::SERIALIZE_WITH = "JSON::Syck";
> 	my $session = new CGI::Session;
> 
> 	Do you think this is a good idea? Or should we have separate modules
> for YAML and JSON?

I think we should have seperate modules. Perhaps they will evolve
differently. The concept of serialization drivers is that each one is
providing a different serializing method. For one serialization driver
to serialize two different ways is a little confusion. 

But for reference, the contortions above shouldn't be necessary anyway.
There way a to pass arguments on through to the serializer through
new().  Here's the related docs:

 "If called with three arguments, first two will be treated as in the previous
  example, and third argument will be \%dsn_args, which will be passed to $dsn
  components (namely, driver, serializer and id generators) for initialization
  purposes. Since all the $dsn components must initialize to some default value,
  this third argument should not be required for most drivers to operate
  properly."

I believe a related convention here is to make keys in this hashref
unique by using a unique prefix, such as "pg_" for the PostgreSQL
driver, etc. 

> >  - adjust the tests to match the limitations of each.
> 
> 	I'm using CGI::Session::Test::Default right now. The tests there are
> in rather large blocks, and only a few things in a few blocks are failing
> with JSON... My first inclination is to either subclass that and copy and
> paste a bunch of stuff, or refactor Test::Default so that certain tests can
> be skipped. I'm thinking supplying our own ok() that runs the test by
> default, but skips it if it's in $self->{skip_tests}.

I like the idea of refactoring so that certain tests can be skipped. I
think the result will be easier to follow when you are done. 

Thanks for that grunt work!

	Mark

Re: [Cgi-session-user] Progress with CGI::Session::Serialize::yaml

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

Mark Stosberg <ma...@su...> wrote:
> I think there are reasons for people to want to use all the different
> drivers. We discussed JSON vs. YAML previously, and ::Syck will be
> preferred for performance when a C compiler is available, otherwise the
> pure Perl versions will be desired. 

> For example, I know I want to keep using YAML::Syck, and I don't care
> about "overloaded objects havin matching addresses".  

	OK, so being that all of the drivers have the exact same interface,
and they're at least forwards-compatible (YAML can read JSON), I'd suggest
that we have one serializer provide all of them. With the current API this
equates to something like:

	my $session = CGI::Session->new(undef, "s=yaml");
	$session->_serializer->use('JSON::Syck');

	or

	local $CGI::Session::Serializer::yaml::SERIALIZE_WITH = "JSON::Syck";
	my $session = new CGI::Session;

	Do you think this is a good idea? Or should we have separate modules
for YAML and JSON?

>  - adjust the tests to match the limitations of each.

	I'm using CGI::Session::Test::Default right now. The tests there are
in rather large blocks, and only a few things in a few blocks are failing
with JSON... My first inclination is to either subclass that and copy and
paste a bunch of stuff, or refactor Test::Default so that certain tests can
be skipped. I'm thinking supplying our own ok() that runs the test by
default, but skips it if it's in $self->{skip_tests}.

		- Tyler

Re: [Cgi-session-user] Progress with CGI::Session::Serialize::yaml

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

On Thu, Feb 23, 2006 at 03:00:25PM -0800, Tyler MacDonald wrote:
> 	I've played around with the four YAML modules people seem most
> interested in (YAML, YAML::Syck, JSON, JSON::Syck). 
> 
> 	- YAML passes all the existing serialization unit tests
> 
> 	- YAML::Syck passes all except the last one (101 - Overloaded
> objects have matching addresses)
> 
> 	- JSON and JSON::Syck fail to rebless references back into their
> original package, but this is pretty much expected behaviour.
> 
> 	What do you think is the best way to move forward? Cosidering all
> those serializers have the same interface, I was thinking of having ::yaml
> default to the regular YAML package, and then if people want they can
> override that with something like
> 
> 	local $CGI::Session::Serializa::yaml::FLAVOUR = "JSON::Syck";
> 
> 	... I would really like to default to YAML::Syck instead since it's
> much much faster, but it doesnt appear to deal with duplicate references as
> well as YAML.

I think there are reasons for people to want to use all the different
drivers. We discussed JSON vs. YAML previously, and ::Syck will be
preferred for performance when a C compiler is available, otherwise the
pure Perl versions will be desired. 

I'll throw out this:

 - document the limitations of each clearly
 - adjust the tests to match the limitations of each.

For example, I know I want to keep using YAML::Syck, and I don't care
about "overloaded objects havin matching addresses".  

Other perspectives?

	Mark

[Cgi-session-user] Progress with CGI::Session::Serialize::yaml

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

	I've played around with the four YAML modules people seem most
interested in (YAML, YAML::Syck, JSON, JSON::Syck). 

	- YAML passes all the existing serialization unit tests

	- YAML::Syck passes all except the last one (101 - Overloaded
objects have matching addresses)

	- JSON and JSON::Syck fail to rebless references back into their
original package, but this is pretty much expected behaviour.

	What do you think is the best way to move forward? Cosidering all
those serializers have the same interface, I was thinking of having ::yaml
default to the regular YAML package, and then if people want they can
override that with something like

	local $CGI::Session::Serializa::yaml::FLAVOUR = "JSON::Syck";

	... I would really like to default to YAML::Syck instead since it's
much much faster, but it doesnt appear to deal with duplicate references as
well as YAML.

	Thoughts?

		Thanks,
			Tyler

Re: [Cgi-session-user] CGI::Session::Serialize::yaml (PATCH)

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

Mark Stosberg <ma...@su...> wrote:
> > 	In a previous email you also suggested moving to Module::Install.
> > How about Module::Build? A 0.28 release is just around the corner and all
> > Module::Install seems to be is syntax sugar around EU:MM/MB.
> 
> I like Module::Build, too. Module::Install makes it easier to migrate a
> custom EU::MM script, which is what we have now. 
> 
> If you want to do the refactor to use /either/, I'll take it.

	Once I hear back from Jason I'll start poking around :)

		- Tyler

Re: [Cgi-session-user] CGI::Session::Serialize::yaml (PATCH)

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

On Thu, Feb 16, 2006 at 05:59:33AM -0800, Tyler MacDonald wrote:
> 
> 	In a previous email you also suggested moving to Module::Install.
> How about Module::Build? A 0.28 release is just around the corner and all
> Module::Install seems to be is syntax sugar around EU:MM/MB.

I like Module::Build, too. Module::Install makes it easier to migrate a
custom EU::MM script, which is what we have now. 

If you want to do the refactor to use /either/, I'll take it.

	Mark

Re: [Cgi-session-user] CGI::Session::Serialize::yaml (PATCH)

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

On Thu, Feb 16, 2006 at 08:57:52AM -0500, Mark Stosberg wrote:
> Tyler,
> 
> Attached is a patch which refactors yaml.pm so that YAML.pm is not
> loaded by default. It's been lightly tested.

Actually, my hot-shot-programmer-lightly-tests-things method didn't work
out so hot for me. Attached is an actually-tested revision that actually
works. 

I believe it may only run the eval("") once in a persistent environment. 

I've just starting using it on a project now! Here's a before and after
snapshot of session rows.

Before:
 $D = {_SESSION_ID => '31e899cf2d95a020bdc911ea78916ccc',_SESSION_ATIME => 1139236810,_SESSION_REMOTE_ADDR => '12.161.105.185',
 _SESSION_CTIME => 1139236810};

After:
 a_session | ---
 BrowseMode: category_list
 _SESSION_ATIME: 1140099124
 _SESSION_CTIME: 1140099099
 _SESSION_EXPIRE_LIST: {}
 
 _SESSION_ID: 2dd493f484b6cb71d590546b2b6f673c
 _SESSION_REMOTE_ADDR: 12.161.105.182
 current_view: month

It's a lot easier to look at.

	Mark





> 
> 	Mark

> --- yaml.pm.orig	2006-02-15 16:35:51.000000000 -0500
> +++ yaml.pm	2006-02-16 08:54:42.087956056 -0500
> @@ -2,32 +2,37 @@
>  
>  use strict;
>  use CGI::Session::ErrorHandler;
> -use YAML ();
>  
> -our $SYCK = eval "use YAML::Syck (); 1;";
> -
> -$CGI::Session::Serialize::yaml::VERSION = '1.0';
> +$CGI::Session::Serialize::yaml::VERSION = '1.1';
>  @CGI::Session::Serialize::yaml::ISA     = ( "CGI::Session::ErrorHandler" );
>  
> +# If neither are already loaded, try loading either one.
> +our $YAML =  _load('YAML::Syck') 
> +     || _load('YAML')
> +     || die "No YAML module found. Install YAML::Syck or YAML: $@ ";
> +import $YAML qw/Load Dump/;
> +
>  sub freeze {
>      my ($self, $data) = @_;
> -    if($SYCK) {
> -        return YAML::Syck::Dump($data);
> -    } else {
> -        return YAML::Dump($data);
> -    }
> +    return Dump($data);
>  }
>  
>  
>  sub thaw {
>      my ($self, $string) = @_;
> -    if($SYCK) {
> -        return (YAML::Syck::Load($string))[0];
> -    } else {
> -        return (YAML::Load($string))[0];
> -    }
> +    return (Load($string))[0];
>  }
>  
> +sub _load {
> +    my $module_name = shift;
> +    eval {
> +        local $SIG{__DIE__};
> +        require $module_name;
> +    };
> +    return $@ ? undef : $module_name;
> +}
> +
> +
>  1;
>  
>  __END__;

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

Re: [Cgi-session-user] CGI::Session::Serialize::yaml (PATCH)

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

Mark Stosberg <ma...@su...> wrote:
> Tyler,
> 
> Attached is a patch which refactors yaml.pm so that YAML.pm is not
> loaded by default. It's been lightly tested.

	Looks good. :) In Test::CPANpm I have a "fake_module" subroutine
that could be used in unit tests to make sure it "actually" loads the
pure-perl version when the XS one isnt available, etc.

	FWIW the YAML.pm requirement in my distro came from the fact that
it's a distro on it's own, if you want to install it and use it you need at
least one YAML and the pure-perl one is the lowest common denominator. (The
distro depends on CGI::Session too, not because it uses it (it doesn't), but
because if *you* want to use Serialize::yaml you'd better have CGI::Session
installed). If it moves into the CGI::Session distro then it becomes more of
a 'plugin' so this approach totally makes sense.

	In a previous email you also suggested moving to Module::Install.
How about Module::Build? A 0.28 release is just around the corner and all
Module::Install seems to be is syntax sugar around EU:MM/MB.

		- Tyler

Re: [Cgi-session-user] CGI::Session::Serialize::yaml (PATCH)

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

Tyler,

Attached is a patch which refactors yaml.pm so that YAML.pm is not
loaded by default. It's been lightly tested.

	Mark

Re: [Cgi-session-user] CGI::Session::Serialize::yaml (JSON, too?)

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

Mark Stosberg <ma...@su...> wrote:
> On Wed, Feb 15, 2006 at 06:57:36PM -0500, Cees Hek wrote:
> > On 2/15/06, Tyler MacDonald <ty...@yi...> wrote:
> > > Mark Stosberg <ma...@su...> wrote:
> > > > I'm a YAML fan too, as well as CGI::Session co-maintainer.
> > >         I'm really glad you support this... having sessions work in a
> > > cross-language way in CGI::Session is going to open the door for some very
> > > powerful mod_perl magic. :)
> > 
> > Might be a good time to support a JSON [1] version as well...
> 
> I'm not sure if you are aware, but JSON is a proper subset of YAML. 
> See:
> http://redhanded.hobix.com/inspect/yamlIsJson.html
> 
> So if we just store the data in JSON format, we've supported both!
> 
> In that sense, it does seem a little silly to have drivers for both, but
> I could see edge cases where people want a feature in YAML that's not in
> JSON...maybe the feature to have references to other parts of the data
> structure. 

	Because they are marketed differently and JSON is just a subset, I
think it makes sense to have serializers for both. Luckily, somebody's
already gone to the trouble of setting up a compatible API for us :

	http://search.cpan.org/dist/JSON-Syck/lib/JSON/Syck.pm

	:-)

		- Tyler

[Cgi-session-user] Questions about integrating YAML driver

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

Hello Tyler,

Here's some more feedback on the YAML driver idea. 

- The version on CPAN requires YAML.pm in the code and Makefile.PL,
  but YAML.pm is not necessary if YAML::Syck is present. I think
  YAML.pm should not be required in this case. 

  In the main distro, I would require neither in the Makefile.PL and at
  most "recommend" them. We may need to switch to using Module::Install
  to have the "recommends" feature, but that's not hard.

- YAML::Syck has some flags, like:
  $YAML::Syck::ImplicitUnicode

  I'm wondering if you've considered supporting any of these options in
  the future. The answer may in fact be a "no-op" since the options can
  be set through these global variables, so no API changes are needed. 

	Mark

Re: [Cgi-session-user] CGI::Session::Serialize::yaml (JSON, too?)

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

On Wed, Feb 15, 2006 at 06:57:36PM -0500, Cees Hek wrote:
> On 2/15/06, Tyler MacDonald <ty...@yi...> wrote:
> > Mark Stosberg <ma...@su...> wrote:
> > > I'm a YAML fan too, as well as CGI::Session co-maintainer.
> >         I'm really glad you support this... having sessions work in a
> > cross-language way in CGI::Session is going to open the door for some very
> > powerful mod_perl magic. :)
> 
> Might be a good time to support a JSON [1] version as well...

I'm not sure if you are aware, but JSON is a proper subset of YAML. 
See:
http://redhanded.hobix.com/inspect/yamlIsJson.html

So if we just store the data in JSON format, we've supported both!

In that sense, it does seem a little silly to have drivers for both, but
I could see edge cases where people want a feature in YAML that's not in
JSON...maybe the feature to have references to other parts of the data
structure. 

	Mark

Re: [Cgi-session-user] Failing DB_File tests

[David S. <dst...@gm...>]

Mark Stosberg wrote:

> On Tue, Feb 14, 2006 at 10:49:58AM -0500, David Steinbrunner wrote:
>> Sherzod Ruzmetov wrote:
>>> 
>>> Matt LeBlanc wrote:
>>>> 
>>>> I had the same problem in FreeBSD. The MANIFEST.SKIP in svn discludes
>>>> these files so the next release should install cleanly.
>>> 
>>> Sorry guys, I think I accidentally added those *.db and *.id files to the
>>> distribution, they shouldn't have been there.
>>> 
>>> I'll take care of it.
>> 
>> I don't know what other items are currently in development for the next
>> release but it would be nice to see a release to fixed this issue so that
>> tests pass in the mean time.
> 
> David,
> 
> I think that's reasonable and I can help make a release soon if Sherzod
> doesn't beat me to it.


Thank you much!

--
David Steinbrunner

Re: [Cgi-session-user] CGI::Session::Serialize::yaml

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

Cees Hek <ce...@gm...> wrote:
> On 2/15/06, Tyler MacDonald <ty...@yi...> wrote:
> > Mark Stosberg <ma...@su...> wrote:
> > > I'm a YAML fan too, as well as CGI::Session co-maintainer.
> >         I'm really glad you support this... having sessions work in a
> > cross-language way in CGI::Session is going to open the door for some very
> > powerful mod_perl magic. :)
> 
> Might be a good time to support a JSON [1] version as well...

	Well, according to http://search.cpan.org/dist/JSON/lib/JSON.pm, it
looks easy enough to do. :-)

		- Tyler

Re: [Cgi-session-user] CGI::Session::Serialize::yaml

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

On 2/15/06, Tyler MacDonald <ty...@yi...> wrote:
> Mark Stosberg <ma...@su...> wrote:
> > I'm a YAML fan too, as well as CGI::Session co-maintainer.
>         I'm really glad you support this... having sessions work in a
> cross-language way in CGI::Session is going to open the door for some ver=
y
> powerful mod_perl magic. :)

Might be a good time to support a JSON [1] version as well...

Cheers,

Cees

[1] http://www.json.org/

Re: [Cgi-session-user] CGI::Session::Serialize::yaml

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

Mark Stosberg <ma...@su...> wrote:
> I'm a YAML fan too, as well as CGI::Session co-maintainer. 
> 
> How about this: We include the YAML serialize in the core distribution,
> but you agree to maintain it, should changes be needed. SVN access can
> be furnished for that purpose.

	Sounds good. Do I need to send you an SSH key or anything?

	I'm really glad you support this... having sessions work in a
cross-language way in CGI::Session is going to open the door for some very
powerful mod_perl magic. :)

> I originally wrote the "PureSQL" driver because I wasn't comfortable
> putting a Perl data structure in the database. It seems wrong, in part
> because of the cross-language access that you mention.
> 
> I do currently using the PostgreSQL for pragmatic reasons, but I would
> still prefer the data be stored in a more accessible format internally, 
> which YAML accomplishes.

	Not just for languages, but for people too! For simple data
structures, it's *much* easier to read than Data::Dumper or XML.

		- Tyler

Re: [Cgi-session-user] CGI::Session::Serialize::yaml

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

On Wed, Feb 15, 2006 at 02:01:58PM -0800, Tyler MacDonald wrote:
> YAML is a notation that represents classes, objects, arrays, hashes, and
> scalars. Perl, PHP, Ruby, Python, and other languages can serialize to and
> from YAML.
> 
> I have written a very simple CGI::Session::Serialize class that serializes
> to/from YAML:
> 
> http://search.cpan.org/~CRAKRJACK/CGI-Session-Serialize-yaml-1.0/lib/CGI/Session/Serialize/yaml.pm
> 
> It uses the fast C-based YAML::Syck when available, or the pure-perl YAML.pm
> otherwise.
> 
> Combining this serializer with, say, a MySQL or Postgres driver opens up the
> door for CGI::Session objects to be shared with other dynamic languages. I'm
> currently using this for a project that is going to have a mod_perl2
> low-level authentication backend, but possibly some PHP pages in the actual
> webspace.
> 
> I'd really like to see something like this make it into the main
> CGI::Session distribution. Working with multiple languages at once is
> becoming more and more common. I uploaded it to CPAN mainly because I'm
> going to be releasing a module that needs it soon; if a YAML serializer
> makes it into CGI::Session itself (a non-dev release), I'd remove mine from
> CPAN and update my module to depend on the latest CGI::Session.

Tyler,

I'm a YAML fan too, as well as CGI::Session co-maintainer. 

How about this: We include the YAML serialize in the core distribution,
but you agree to maintain it, should changes be needed. SVN access can
be furnished for that purpose.

I originally wrote the "PureSQL" driver because I wasn't comfortable
putting a Perl data structure in the database. It seems wrong, in part
because of the cross-language access that you mention.

I do currently using the PostgreSQL for pragmatic reasons, but I would
still prefer the data be stored in a more accessible format internally, 
which YAML accomplishes.

	Mark

[Cgi-session-user] CGI::Session::Serialize::yaml

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

YAML is a notation that represents classes, objects, arrays, hashes, and
scalars. Perl, PHP, Ruby, Python, and other languages can serialize to and
=66rom YAML.

I have written a very simple CGI::Session::Serialize class that serializes
to/from YAML:

http://search.cpan.org/~CRAKRJACK/CGI-Session-Serialize-yaml-1.0/lib/CGI/Se=
ssion/Serialize/yaml.pm

It uses the fast C-based YAML::Syck when available, or the pure-perl YAML.pm
otherwise.

Combining this serializer with, say, a MySQL or Postgres driver opens up the
door for CGI::Session objects to be shared with other dynamic languages. I'm
currently using this for a project that is going to have a mod_perl2
low-level authentication backend, but possibly some PHP pages in the actual
webspace.

I'd really like to see something like this make it into the main
CGI::Session distribution. Working with multiple languages at once is
becoming more and more common. I uploaded it to CPAN mainly because I'm
going to be releasing a module that needs it soon; if a YAML serializer
makes it into CGI::Session itself (a non-dev release), I'd remove mine from
CPAN and update my module to depend on the latest CGI::Session.

	Thanks,
		Tyler

Re: [Cgi-session-user] Failing DB_File tests

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

On Tue, Feb 14, 2006 at 10:49:58AM -0500, David Steinbrunner wrote:
> Sherzod Ruzmetov wrote:
> >
> > Matt LeBlanc wrote:
> >>
> >> I had the same problem in FreeBSD. The MANIFEST.SKIP in svn discludes
> >> these files so the next release should install cleanly.
> >
> > Sorry guys, I think I accidentally added those *.db and *.id files to the
> > distribution, they shouldn't have been there.
> > 
> > I'll take care of it.
> 
> I don't know what other items are currently in development for the next
> release but it would be nice to see a release to fixed this issue so that
> tests pass in the mean time.

David,

I think that's reasonable and I can help make a release soon if Sherzod
doesn't beat me to it.

	Mark

Re: [Cgi-session-user] Failing DB_File tests

[David S. <dst...@gm...>]

Sherzod Ruzmetov wrote:
>
> Matt LeBlanc wrote:
>>
>> I had the same problem in FreeBSD. The MANIFEST.SKIP in svn discludes
>> these files so the next release should install cleanly.
>
> Sorry guys, I think I accidentally added those *.db and *.id files to the
> distribution, they shouldn't have been there.
> 
> I'll take care of it.

I don't know what other items are currently in development for the next
release but it would be nice to see a release to fixed this issue so that
tests pass in the mean time.

Thanks,

--
David Steinbrunner

Re: [Cgi-session-user] session data not being saved till flushed.

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

On Mon, Feb 13, 2006 at 09:24:40AM -0500, James.Q.L wrote:
> 
> --- Mark Stosberg <ma...@su...> wrote:
> 
> > On Sat, Feb 11, 2006 at 11:30:47PM -0500, James.Q.L wrote:
> > > HI,
> > > 
> > > I am using C::S 4.03 and the session data is not saved unless i call flush(). The doc claims
> > > otherwise, "Normally it will be called for you just before the program terminates, or session
> > > object goes out of scope, so you should never have to flush() on your own."
> > 
> > Hello James,
> > 
> > There are now several bug reports filed about related behavior,
> > including one I filed myself just a few days ago:
> > 
> > http://rt.cpan.org/Public/Bug/Display.html?id=17541
> > 
> > This much is clear:
> > 
> > - For some people flush() used to happen automatically with 3.95, but quit working
> >   with 4.00 (and still isn't fixed in 4.03).
> > 
> > - It's possible for third party modules to break the automatic flush() behavior, which 
> >   I've confirmed myself. This can happen by creating a circular reference, so that the
> >   DESTROY method isn't invoked as expected. 
> > 
> > My proposal to address the situation is quit relying on flush() happen
> > automatically, and recommend that people use an explicit flush()
> > instead, which works reliably for everyone.
> > 
> > That's what I'm doing. Actually, since I use CGI::Application, I just
> > call flush() in teardown() and forget about it the rest of the time. 
> > This currently does have some overhead because it means that a session
> > ma created at that moment so that flush() can be called on it!
> 
> how did CGI::Session handle the flush overhead before? 

In the original design, there was no significant overhead. flush was
called as part of DESTROY(), which happens when an object goes out of
scope, and is not to be confused with an END{} block, which happens at
the end of every request.  flush() was only called on objects that were
created, and only tried to update the storage backend if there was
anything to flush.

My suggestion for use with CGI::Application is more like the END{} block
case, which happens at the end of every request. Since a session might
not otherwise be created during a specific request, there's overhead 
in the possibility of a session being created for no real use. 

This is easily addressable by adding like "session_is_loaded()" method
to CGI::Application::Plugin::Session. Then you can check to see if a
session actually exists first, and only call flush() if there is one
there.

	Mark

Re: [Cgi-session-user] session data not being saved till flushed.

[James.Q.L <shi...@ya...>]

--- Mark Stosberg <ma...@su...> wrote:

> On Sat, Feb 11, 2006 at 11:30:47PM -0500, James.Q.L wrote:
> > HI,
> > 
> > I am using C::S 4.03 and the session data is not saved unless i call flush(). The doc claims
> > otherwise, "Normally it will be called for you just before the program terminates, or session
> > object goes out of scope, so you should never have to flush() on your own."
> 
> Hello James,
> 
> There are now several bug reports filed about related behavior,
> including one I filed myself just a few days ago:
> 
> http://rt.cpan.org/Public/Bug/Display.html?id=17541
> 
> This much is clear:
> 
> - For some people flush() used to happen automatically with 3.95, but quit working
>   with 4.00 (and still isn't fixed in 4.03).
> 
> - It's possible for third party modules to break the automatic flush() behavior, which 
>   I've confirmed myself. This can happen by creating a circular reference, so that the
>   DESTROY method isn't invoked as expected. 
> 
> My proposal to address the situation is quit relying on flush() happen
> automatically, and recommend that people use an explicit flush()
> instead, which works reliably for everyone.
> 
> That's what I'm doing. Actually, since I use CGI::Application, I just
> call flush() in teardown() and forget about it the rest of the time. 
> This currently does have some overhead because it means that a session
> ma created at that moment so that flush() can be called on it!

how did CGI::Session handle the flush overhead before? 

thank you for the headsup and I am back to use flush().
 
> New functionality may be added to the Session plugin to address that.
> 
> I have commit and release access for the CGI::Session project, but I
> wanted to get feedback from other people on the issue before proceeding.
> 
> I know these flush() issues can be frustrating and time consuming to
> trackdown, so I'd like to address it soon. 

great! let me know if i can be any help.
 
> 	Mark
> 

James.


	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

Re: [Cgi-session-user] session data not being saved till flushed.

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

On Sat, Feb 11, 2006 at 11:30:47PM -0500, James.Q.L wrote:
> HI,
> 
> I am using C::S 4.03 and the session data is not saved unless i call flush(). The doc claims
> otherwise, "Normally it will be called for you just before the program terminates, or session
> object goes out of scope, so you should never have to flush() on your own."

Hello James,

There are now several bug reports filed about related behavior,
including one I filed myself just a few days ago:

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

This much is clear:

- For some people flush() used to happen automatically with 3.95, but quit working
  with 4.00 (and still isn't fixed in 4.03).

- It's possible for third party modules to break the automatic flush() behavior, which 
  I've confirmed myself. This can happen by creating a circular reference, so that the
  DESTROY method isn't invoked as expected. 

My proposal to address the situation is quit relying on flush() happen
automatically, and recommend that people use an explicit flush()
instead, which works reliably for everyone.

That's what I'm doing. Actually, since I use CGI::Application, I just
call flush() in teardown() and forget about it the rest of the time. 
This currently does have some overhead because it means that a session
ma created at that moment so that flush() can be called on it!

New functionality may be added to the Session plugin to address that.

I have commit and release access for the CGI::Session project, but I
wanted to get feedback from other people on the issue before proceeding.

I know these flush() issues can be frustrating and time consuming to
trackdown, so I'd like to address it soon. 

	Mark