Re: is my approach to using DB_DataObject sensible?

Thanks, Justin. Some comments on your response:

On 9/26/05, Roger Rohrbach <roger@ecstatic.com> wrote:

Hello, I'm using DB_DataObject for the first time. After playing around with it a bit, and given the following: * I don't want to edit the auto-generated classes

Why not? This is the sensible way to do things. My schema is in flux, and leaving the auto-generated classes alone allows me to update them automatically when the schema changes, rather than maintain them by hand.

* I want to override the fetch() method, as suggested in the

     documentation, to add properties that are not stored in the
     underlying tables
   

I now realize I can do this without extending the base classes (I'd confused them with the DB_DataObject class that originally defines this method). But I still like keeping my application code out of the auto-gen'd classes.

/*

    * Load the base class (DataObject_User).  There's no way to do this

without

    * instantiating, but we discard the resulting object because we're

extending

    * the class.
    */

DB_DataObject::Factory('User');

You don't have to use factory here if all you're doing is loading the class. You can use require_once(). However, I think that altering the auto-gen class would be a much better solution. The docs say calling the factory is the preferred way to both load classes and instantiate. I looked at the source and decided it doesn't do anything significant, so I'm just using require_once() as you suggest.

           // override fetch() to add 'role' to the object:

           function fetch() {

                   if ($result = parent::fetch()) {

                           $this->role = $this->getLink('role_id');
                   }

                   return $result;
           }
   

Are you sure you want to do another query every time you fetch? This is going to cause a whole new query to the DB, which can cause slowness. This is especially a bad idea if you're not using this data every time you fetch a User record. It would be better to just getLink in the calling script. I'm aware of the cost, but the User object is presently a singleton (representing the logged-in user). When I add user management or other functionality that manipulates sets of users, I'll likely change the class to fetch the related data on demand. I won't make the app call getLink(), though; I'll add a method like "role()" that fetches (and caches) the related data, by calling getLink(). Ideally, my app will only use get(), find(), fetch() etc.

thx, Roger