Re: Apache::Session, DBD::Oracle

2000-02-09 Thread Mark Dedlow

Greg Stark wrote:

> [EMAIL PROTECTED] (Robert Locke) writes:
> 
> > - store this string into Oracle  (type is LONG)
> 
> You really really don't want to be using LONG btw. How large is the data
> you're really storing anyways? Oracle can do varchars up to 2k unlike some
> other pesky databases.

And 4K in 8.1

> LONGs have a number of problems, you can't export/import them, you can't
> create table as select to copy them to a new table etc. They also allegedly
> make your tables slow to access, though I don't know the details. 

In a nutshell:

Complete rows are stored in blocks. Blocks are the smallest unit of I/O.
So you're always doing I/O equal to the size of the rows no matter
how many columns you need.  In other others, "select COL1 from table"
does the same physical I/O as "select * from table".  

If a table has a sizable LONG column that most SQL ignores, you 
end up doing lots of needless I/O.  But this is not specific to LONGs.
A table with 100 full Varchar2(2000) columns requires the same I/O
as a table with 1 100*2000 LONG column.

Mark



Re: Apache::Session, DBD::Oracle

2000-02-08 Thread Greg Stark


[EMAIL PROTECTED] (Robert Locke) writes:

>   - store this string into Oracle  (type is LONG)

You really really don't want to be using LONG btw. How large is the data
you're really storing anyways? Oracle can do varchars up to 2k unlike some
other pesky databases.

LONGs have a number of problems, you can't export/import them, you can't
create table as select to copy them to a new table etc. They also allegedly
make your tables slow to access, though I don't know the details. I don't know
if BLOBs are any different though. 

I do wonder whether you're making good use of your database to be storing
information as frozen perl data structures. It's flexible but it can't be very
fast and it doesn't buy you the data mining abilities having a database is
good for.

-- 
greg



Re: Apache::Session, DBD::Oracle

2000-02-08 Thread Perrin Harkins

On Wed, 9 Feb 2000, Robert Locke wrote:
> We've been using the latest Apache::Session::DBI with some success
> using Oracle 8i (DBD::Oracle 1.03) as the data store.  (Basically, we
> applied Ajit Deshpande's recommendation of patching DBIStore.pm with a
> large number for LongReadLen.  See
> 
>http:[EMAIL PROTECTED]
> for reference.)
[...]
> To make a long story short, it seems that storing and then fetching a
> binary string is broken, but I'm not sure if this is an Oracle or DBD
> issue, or if I'm just doing something plain silly.

It's my understanding that Oracle doesn't want you to use Long anymore.
They prefer BLOB for this and are phasing out Long.  Maybe they broke Long
in the 8i release for certain situations.

BLOB works fine from DBD::Oracle, so give it a try.  You may need to set
the type on the bind parameter to ORA_BLOB.  perldoc DBD::Oracle for the
scoop.

- Perrin




Apache::Session, DBD::Oracle

2000-02-08 Thread Robert Locke

Hi,

We've been using the latest Apache::Session::DBI with some success
using Oracle 8i (DBD::Oracle 1.03) as the data store.  (Basically, we
applied Ajit Deshpande's recommendation of patching DBIStore.pm with a
large number for LongReadLen.  See
http:[EMAIL PROTECTED]
for reference.)

We recently added some more data to our session hashes and everything
broke.  In trying to track the problem down, we've been able to
replicate it OUTSIDE of Apache by writing a Perl script which
simulates Apache::Session and does the following:

- create a fairly large hash
- convert it to a binary string using Storable::nfreeze
- store this string into Oracle  (type is LONG)
- fetch string from the database
- compare fetched string to the original string
- convert fetched string back to a hash using Storable::thaw

The above works great under our development environment, where we are
using Oracle 8.0.5.  But, in our production environment, where we are
using Oracle 8i, the fetched string differs from the original and we
cannot convert it back into the original hash.

To make a long story short, it seems that storing and then fetching a
binary string is broken, but I'm not sure if this is an Oracle or DBD
issue, or if I'm just doing something plain silly.

Any pointers would be appreciated.

Thanks,

Rob

PS. I'm attaching the code as reference.


 teststore.pl