Re: cvs: /php3 ChangeLog
| From: | Zeev Suraski | Date: | Wed, 24 Nov 1999 19:47:47 +0000 |
| Subject: | Re: cvs: /php3 ChangeLog | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-13072@lists.php.net to get a copy of this message | ||
On Wed, 24 Nov 1999, Sascha Schumann wrote:
> On Tue, Nov 23, 1999 at 08:18:01AM -0500, Rasmus Lerdorf wrote:
> > > or did i miss something?
> >
> > No, you didn't miss anything. Some bugs popped up and I have been slow in
> > addressing them. The main thing left at this point is that the
> > mysql_change_user() function needs to modify the hashed information for
> > the persistent connection it modifies.
>
> This could be easily solved, if the MySQL module would not be
> affected by a bad design decision which has been made for
> many other modules as well.
We can argue on whether this is a bad design or not, but it's basically a
question of whether you keep things quick, or remain open for possible
future improvements you can't really fortell. At the time, change_user()
wasn't dreamt of, and keeping things as quick as possible was the number
one priority.
I don't think that there's anything holy about the way the MySQL module
works when it comes to persistence. I wouldn't go about adding
change_user() support by going over the list and rehashing afterwards, but
rather, by modifying the entire architecture not to use user/password as a
part of the key. It's not as if it's a big deal to change; Just as much,
I wouldn't change it in databases that don't support the notion of
change_user(). It's not a bad design issue (ok, so I'm arguing a bit :)
I'll refamiliarize myself with my old code (and the new code) and modify
it to this concept in the weekend.
Zeev
--
-----------------------------------------------------
Zeev Suraski <zeev@zend.com> http://www.zend.com/