[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: FIX: Apache::Session-0.99.8 and DBD::Pg
From:       dean () brettle ! com
Date:       1999-05-30 18:14:46
[Download RAW message or body]

"Jeffrey W. Baker" wrote:
> 
> dean@brettle.com wrote:
> >
> > Hello again...
> >
> > I tried using Apache::Session::DBI with PostgreSQL (DBD::Pg) and ran
> > into a snag.  Apache::Session::DBIStore uses Storable to do
> > serialization.  Storable produces a *binary* string which can (and often
> > does) contain \0s.  DBD::Pg has no way of quoting these and the result
> > is:
>
> DBD::Pg::st execute failed: ERROR:  parser: parse error at or near ""

> I'll take this patch into consideration, but I don't know if I want it
> to be mandatory.  Some of us have a man's database that can store binary
> data :0

:-)  FWIW, PostgreSQL can handle BLOBs, but I'm not sure if it can
handle binary data passed directly in SQL.  If it can and it just needs
be specially quoted then the problem is in DBD::Pg::quote() and/or
DBD::Pg::bind_param().  BTW, it looks like DBD::Pg fakes placeholders
because I don't think PostgreSQL supports them.  Not sure though.  Also,
does DBI specify that DBDs must support binary valures?  Or is this just
common to most DBDs?  If support for binary values is specified then
this is actually a bug in DBD::Pg and not Apache::Session.  But I don't
see how DBD::Pg could workaround the PostgreSQL limitation in this
case.  I've CCc dbi-users on this in hopes that someone there can shed
some light on the subject.

> 
> Perhaps I'll make it a configuration option, but I don't want to incur
> the penalty of uuencoding a large binary object, then storing the
> now-bloated ascii string in the database.  For those of use using
> Oracle, DB2, MSSQL, MySQL, and almost all other popular databases, this
> would be needless overhead.

FWIW, I suspect that the uuencoding time is neglible compared to the
freeze time, but I haven't run any benchmarks.  Space overhead should be
under 15%.

> 
> How about a config switch StoreASCII => 1?

That would be fine.  I'd argue that StoreASCII => 1 should be the
default to provide the broadest DBD support.  People could set
StoreASCII => 0 if they are willing to sacrifice portability for speed. 
Also, you might want to consider defaulting to nfreeze instead of freeze
in case the DB is accessed by machines with different archs.

IMO, it would be really sweet to be able to configure the serializer as
an option to storage manager.  So I could choose between, for example,
StorableSerializer, FreezeThawSerializer, and DataDumperSerializer. 
MLDBM seems to work that way.  Maybe I should just write an
Apache::Session::MLDBMStore.

-- Dean

+--------------------------------------------------------------------+
|    Dean Brettle Computer Consulting     http://www.brettle.com/    |
|      Contract development and support of software and systems      |
+--------------------------------------------------------------------+

[prev in list] [next in list] [prev in thread] [next in thread]