On Tue, 2003-07-01 at 19:51, Wez Furlong wrote:
> What is the point of publishing a benchmark if you are not comparing an SQL
> data store with an SQL data store?
Speaking of bullshit comparisons :)
One is a client/server architecture, the other is a direct disk access
architecture. Using an RDBM gives you tons of other advantages,
including efficient replication (separating read servers from write
servers for example), integration with existing storage systems, etc.
You actually *win* something when you use a RDBM.
With SQLite sessions you just lose.
>
> > I will commit my fixes, if the decision is to bundle sqlite. Or someone
> > is interested in trying it out in the interim.
>
> Commit it.
Fine.
>
> > Also note, this would mean that all
> > shared hosts go to a single sqlite database, instead of a directory.
> > One site may not get a lot of hits, but an entire shared host would.
> > This directive is per-php ini, and has to be.
>
> Huh?
> Thats bullshit.
> session.save_path allows you to configure the database per virtual host.
> There is no restriction that forces an entire server to use the same dir.
>
> Each server should use a seperate save path anyway (or have you never had
> problems with session collisions between vhosts?).
Does that work currently with sqlite? If so, then its fine. I stand
corrected.
>
> > Why would you get your own server to serve one website if performance
> > wasn't important? You wouldn't. Further, Why would you use SQLite
> > instead of the files based system? Give me a problem this solves.
>
> This is also pure excrement.
>
> > >
> > > Yes, "enterprise" sites would be stupid to use sqlite for session
> storage,
> > > but then, enterprise sites probably won't be using sqlite at all.
> >
> > I'm not talking about enterprise sites. I didn't mention that once in
> > fact. I'm talking about your every day average people, using php on a
> > shared host.
>
> and everyday users cluster their sessions...
Plenty of non "enterprises" do.
> > In general database backends make no sense for sessions support, unless
> > you want to integrate into a pre-existing architecture, or you want to
> > cluster (and even then its iffy). The Sqlite sessions supports allows
> > you to do neither of these things. Its not easier to use, its a 300%
> > slowdown, and its not nearly as "safe" in shared environments (you can't
> > have different users for different sessions safely.)
> >
> > So why add it?
>
> Because it is a single .c file logically grouped with the rest of the
> library that we bundle.
Fine. Perhaps I should add a export_privates() function to ext/standard
than. It would export all private class variables into the current
scope. Just because something fits somewhere, doesn't mean it should be
there.
>
> If you hate it so much, lets just unbundle the whole sqlite extension.
>
I don't "hate" SQLite. I just think right tool for the right job.
SQLite is not a good *generic* tool for managing sessions, not one
person has given a real world case where this helps them. Give me one
which has a 'practical advantage' from using a *generic* SQLite, and
I'll stop this discussion.
-Sterling
> --Wez.
--
"Reductionists like to take things apart. The rest of us are
just trying to get it together."
- Larry Wall, Programming Perl, 3rd Edition
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
