Re: New PDO-based DBAL/ORM for PEAR2

On Nov 21, 2007, at 1:41 AM, Bertrand Mansion wrote:

Le 21 nov. 07 à 09:11, Bertrand Mansion a écrit :

Singleton doesn't create a new database instance. Instead, if you are connecting with the same DSN, username, and password, it will return the same database connection that has already been established with that combination. It's nice so that you don't create multiple database connections with the exact same connection parameters.

I use named connections for that and only one method : getConnection($id = '__default__) IMO, no need for a meaningless singleton method. It's appealing at first to use such method names in your code but it just confuse users in the end because they have no idea what a singleton is or what will be returned.

Actually I use Session objects which hold each a distinct pdo object. Sessions are created with Phreez::connect($pdo, $id = '__default__'). Then, if I want to switch to another session, I use Phreez::useSession($id = '__default__).

I really like the idea of connection aliases, and I already use them in PDORM_Domain::addConnection() and PDORM_Domain::getConnection(). Also, there is the possibility of using PDORM_Connection::instanceIndex() to get that connection's unique id that can be used to retrieve it later using PDORM::getConnectionInstance(). $db = PDORM::factory('mysql:host=localhost', 'user', 'pass'); $_GLOBALS['myDBInstances']['default'] = $db->instanceIndex(); ... $db = PDORM::getConnectionInstance($_GLOBALS['myDBInstances']['default']); // get the same connection So I think that what you're talking about is already possible (admittedly, I need to improve the implementation). I don't use multiple database connections much, so I'm not very familiar with managing them. However, consider the following scenario: I have my DSN, username, and pass stored in some file somewhere, and I need to get the same database connection. So I invent an alias and create the connection: require_once 'db.inc'; $db = PDORM::factory('__default__', $dsn, $user, $pass); // okay...remember __default__ Later, in some other file, I need the same connection. Hmm...what was that alias I used? Oh yeah...__default__... require_once 'db.inc'; $db = PDORM::getConnectionInstance('__default__'); Instead of keeping a list of aliases in my head, wouldn't it be easier to say forget the aliases, I'll try and connect again with the exact same parameters and PDORM should be smart enough to figure it out! require_once 'db.inc'; $db = PDORM::singleton($dsn, $user, $pass); ... require_once 'db.inc'; $db = PDORM::singleton($dsn, $user, $pass); So I can either manage a list of connection aliases in my head, or I can let PDORM do it for me and just use PDORM::singleton(). I personally think the latter is easier and requires less work on my part. At least that's what I was thinking when I coded it. The only reason that I use connection aliases in PDORM_Domain is because the mapper's may them to specify which connection instance to use: PDORM_Domain::addConnection('__default__', $dsn, $user, $pass); class Mapper_Author extends PDORM_Domain_Mapper {

    protected $conn_alias = '__default__';

}

Thinking about it, my Session objects might look like your Domains and hold information about objects already loaded(?).

Does the fact that you're using sessions mean that you are actually using PHP sessions? How do you restore the connection upon subsequent requests? Do you keep it open between requests? IMO, that's interfering too much with the session...the user might not even want to use sessions in his application...please clarify if I'm way off here.

For handling relations, I don't use RoR has_many etc, I think it's not good. I use a RelationRegistry that hods information about all the relations between objects in the database. Relations are represented as objects, they are able to automatically create joined queries for select, updates, etc. The RelationRegistry can be queried at any time by any other object.

Is your registry an XML file? How do you initially set up the relations? I am all for finding a better way to do this because I'm not sure that ROR has the best implementation, but it's a good one. Thanks, Michael