On Fri, 26 May 2000, Jeffrey W. Baker wrote:
> > A couple of notes on the Oracle storage module:
> >
> > - Using "FOR UPDATE" forces the transactional lock model. Is it possible
> > to make this optional? The other modes allow the use of a "enforce data
> > integrity only" locking style which is sometimes needed. I'm less worried
> > about people overwriting their own session data than I am about stale
> > locks, although I suppose Apache::DBI's cleanup handler should take care
> > of them.
>
> I assume that if people are using a transactional database, they are
> knowledgable about transactions. That's why I made the Commit argument
> mandatory for the Oracle and Postgres backing stores: it forces people to
> consider their transaction policy.
My only complaint, and it's one I can easily solve by editing the source,
is that I can't get the "no locks, just atomic updates" policy that I
currently use in the new module, even if I use the Null locker.
> > - Oracle (the company) says not to use LONG anymore. They are trying to
> > move everything to CLOB/BLOB. I modified my Apache::Session::DBI to
> > support this, which mostly involved specifying "ora_type => ORA_BLOB" in
> > my bind variable parameters. Maybe we need and Oracle8 module, separate
> > from the standard one? By the way, BLOBs don't work with synonyms, so you
> > have to specify the schema name in the SQL when using them.
>
> That's lame. So, we would need to pass the schema name as an
> argument? Remind me again what's wrong with LONG?
>From my perspective, nothing at all. I think they even perform better
than BLOB at the moment, at least through DBI. The problem is, Oracle is
phasing them out and will eventually drop support for them entirely.
They don't want to admit that BLOBs breaking synonyms is a bug either.
- Perrin
