Re: Removing SQLite sessions from the defaultdistribution
| From: | Wez Furlong | Date: | Tue, 01 Jul 2003 23:51:23 +0000 |
| Subject: | Re: Removing SQLite sessions from the defaultdistribution | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-3132@lists.php.net to get a copy of this message | ||
What is the point of publishing a benchmark if you are not comparing an SQL
data store with an SQL data store?
> 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.
> 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?).
> 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...
> They wouldn't use sqlite, because it requires that every
> person on the shared host use sqlite (and I doubt anyone would use
> per-dir).
again...
> 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.
If you hate it so much, lets just unbundle the whole sqlite extension.
--Wez.