Re: DB singleton function?

From: Date: Thu, 28 Oct 2004 13:03:02 +0000
Subject: Re: DB singleton function?
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-34119@lists.php.net to get a copy of this message
> On Wednesday 27 October 2004 07:40 pm, Hans Lellelid wrote: >> Hi Ian - >> >> >Yeah... I know how singletons work, I'm just not sure if it should >> connect >> > to the DB or just create the instance. >> >> One thing related to this topic .... some APIs like mysql (is mysql the >> only one?) will re-use existing connections if you pass in the same >> connection parameters. >> > It depends on the DB driver. foo_pconnect() generally uses a persistent > connection, whereas foo_connect() does not. No -- check the docs for mysql_connect() to see what I'm talking about. > Regardless, DB is a fairly large class, and having multiple instances of > it > isn't a good idea. > > >> WI'd suggest that this behavior be avoided (by >> passing a force-new-connection arg to mysql_[p]connect() method) and >> that a singleton be implemented instead. Perhaps the [M]DB libs already >> do this, but the reason why [M]DB does a mysql_select_db() before every >> query is precisely this: that you cannot otherwise use two databases on >> the same server, since the _same_ db link id would have been returned >> for both connections. >> > Not quite sure what you mean... pconnect() should only return the same > link > when fed the same parameters... singleton() would act the same way, with > one > instance per DSN. If you call singleton() with the same DSN twice, you > should > get the same instance. Yes, agreed -- the only thing I was bringing up is that some drivers (well, mysql) *natively* are doing something like singleton by returning the same connection id. Things could get really confusing if you think you're creating a new connection to the same server, when in fact it will return the connection it already created. > >> Yeah, anyway, I think the singleton() addition is a good idea; it's good >> it exists in MDB2. Personally, I think that the name singleton() is >> pretty jargon-esque, and that getInstance() might be clearer, but that's >> just my opinion. >> > factory() is generally the method used to get a new instance; singleton() > behaves differently. > Yes, well -- packages like Log, other Horde packages, and probably MDB2 use singleton with params to store instances that were created by factory(). factory() is different, in that it does not imply that you will get an already-created instance back if it exists. >> I think technically the singleton implemented by MDB >> (or see almost any of the core Horde classes for similar >> implementations) is not a "singleton" at all since there is more than >> one instance (i.e. one instance per DSN), and by definition singleton > >> 1 instance. >> > I believe that one instance per DSN is perfectly acceptable for situations > like this, and I believe that is the intent of the singleton() method in > the > first place. Well, perhaps. All the definitions that I've seen of "singleton" indicate that it means exactly one copy of the class. If a method is going to be named after a pattern (which is what I was saying was ratehr jargon-esque, as opposed to something more flexible & intuitive like getInstance()) it should probably be named after the right pattern. -Hans

« previous php.pear.dev (#34119) next »