PHP Pear - Re: [PEAR] is my approach to using DB

Author

Re: [PEAR] is my approach to using DB_DataObject sensible?

Justin Patrin

2005-09-26, 6:57 pm

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.

> * I want to define behaviors for my database objects
> * I want to override the fetch() method, as suggested in the
> documentation, to add properties that are not stored in the
> underlying tables
>
> I've decided to extend the auto-generated classes and use the new
> classes in my application.
>
> As a concrete example, here's the User class for my Web app:
>
> <?php
>
> require_once('DB/DataObject.php');
>
>
> /*
> * 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.

>
>
> class MyAppUser extends DataObject_User {
>
> var $role;
>
>
> // override fetch() to add 'role' to the object:
>
> function fetch() {
>
> if ($result =3D parent::fetch()) {
>
> $this->role =3D $this->getLink('role_id');
> }
>
> return $result;
> }
> }
>
> ?>
>
>
> 'Role_id' is the foreign key of a UserRole table.
>

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'd like to get feedback on whether this is a sensible approach. In
> particular: am I correct in saying that DB_DataObject::Factory() is the
> only way to load the class? I can't extend the class until it's
> loaded. It seems a bit inelegant, but I've not seen any other way to do
> this.
>
> Comments welcome.
>

--
Justin Patrin

Roger Rohrbach

2005-09-28, 6:58 pm

Thanks, Justin. Some comments on your response:

>On 9/26/05, Roger Rohrbach <roger@ecstatic.com> wrote:
>
>
>
>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 now realize I can do this without extending the base classes (I'd

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.
[color=darkred]
>
>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.

>
>
>
>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

James Stewart

2005-09-28, 6:58 pm

On Sep 28, 2005, at 3:53 PM, Roger Rohrbach wrote:
> Justin Patrin wrote:
>
> 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 regularly work with DB_DataObject while my schemas are in flux. So
long as you place your code beneath the lines:

/* the code above is auto generated do not remove the tag below */
###END_AUTOCODE

Then when you regenerate the DOs your code will remain intact.

James.

--
James Stewart
Play: http://james.anthropiccollective.org
Work: http://jystewart.net

Roger Rohrbach

2005-09-29, 9:57 pm

Thanks again, Justin (and James Stewart, who also pointed this out).
For some reason, I completely missed the fact that createTables.php
preserves material added below "###END_AUTOCODE ".

>You can alter the autogen classes while still updating the schema
>automatically. Just put your edits outside of the auto-gen comments.
>
>

Sponsored Links