 |
|
|
| View previous topic :: View next topic |
| Author |
Message |
pixelterra
Joined: 29 Feb 2008
Posts: 9
|
 Posted: Fri Feb 29, 2008 7:24 am Post subject: DB_TABLE why do you need to pass the table name? |
 |
|
Why does the DB_TABLE class not define the table name within the class definitions along with cols and indexes so that you have to manually pass the table name on instantiation as shown below? This is from the DB_TABLE documentation here:
| Code: | // create a PEAR MDB2 (or DB) object
$dsn = "phptype://username:password@localhost/database";
$conn = MDB2::connect($dsn);
// set up for the GuestBook and create it
$table = 'GuestBook';
$create = 'safe';
$GuestBook =& new GuestBook_Table($conn, $table, $create); |
If you can define all the cols and indexes etc, why can't you define the table name. What am I missing? This just seem like an unnecessary step each time you instantiate the object.
I've taken a look at the source code and it would be a simple matter to change it so that the table name can be set in the table definition with the rows, etc, but I don't want to screw things up if I neet to upgrade this script in the future.
Surely the developers thought of this, but I cannot see the benefit... Anyone care to enlighten me? |
|
| Back to top |
|
 |
mark
Joined: 07 Jan 2007
Posts: 1011
|
| Posted: Fri Feb 29, 2008 1:49 pm Post subject: Re: DB_TABLE why do you need to pass the table name? |
|
|
| pixelterra wrote: | | Why does the DB_TABLE class not define the table name within the class definitions along with cols and indexes so that you have to manually pass the table name on instantiation as shown below? |
I don't know the motivation of Paul M. Jones (the original author of this package) to make the API this way, but I (the current maintainer of this package) use my table definition classes often for multiple (physical) database table that are (quite) similar. One could see the table definition also in relation to the first parameter which is the database object, including the database name. And with the second parameter you'll simply add also the table name to these "definitions".
Anyway, I also see your point that in some cases it is also useful to define the table name in the class. You're welcome to send a feature request via PEAR's bug tracker, ideally with a patch attached (but that's not required). I can't promise whether I'll find time for this request in the next weeks, but I won't forget it if you add it to the bug tracker. |
|
| Back to top |
|
|
pixelterra
Joined: 29 Feb 2008
Posts: 9
|
| Posted: Fri Feb 29, 2008 4:51 pm Post subject: |
|
|
Thanks for the quick reply. I'm asking this question because I haven't really used it yet, and am shopping around for the best method for DB objectification. So I might not decide to use DB_TABLE.
Because of that, I don't feel comfortable at present making a feature request since I haven't even used the scripts for any length of time. Perhaps on using DB_TABLE for a while, I'll come to see it your way. So I'll just try it and wait.
However I've used many frameworks before and the ones I tend to like best use "convention" over "configuration", so in this case the most efficient thing to do in my opinion, would be to actually have DB_TABLE extract the name of the db table from the actual class name, that way you don't have to configure it anywhere, and simple instantiation is all you need.
Of course for flexibility, it would also be effective to be able to override this behavior when necessary, which theoretically would be less often than one needs the standard "one table - one class" system.
Not trying to correct you here, just providing an outside opinion. Thank you for your time in maintaining this software. I appreciate your work and other OS developers.
BML |
|
| Back to top |
|
|
pixelterra
Joined: 29 Feb 2008
Posts: 9
|
| Posted: Fri Feb 29, 2008 4:57 pm Post subject: |
|
|
Sorry, one more question for you: in the event that I decide to want to use DB_TABLE, and to define my table name in the class, what would be the least invasive way to do this that still makes upgrades to DB_TABLE, not too difficult?
On a brief look, it looks like I could just define $this->table in the class, and remove the 2nd parameter from the constructor. Of course I would have to alter the source every upgrade.
It also looks as though I might leave the source alone and define a constructor for each subclass, which doesn't require the table name, and then calls the parent constructor, passing the connection and $create info.
Any opinion on this, including "just leave it alone"? : ) |
|
| Back to top |
|
|
mark
Joined: 07 Jan 2007
Posts: 1011
|
| Posted: Fri Feb 29, 2008 5:23 pm Post subject: |
|
|
| pixelterra wrote: | Sorry, one more question for you: in the event that I decide to want to use DB_TABLE, and to define my table name in the class, what would be the least invasive way to do this that still makes upgrades to DB_TABLE, not too difficult?
On a brief look, it looks like I could just define $this->table in the class, and remove the 2nd parameter from the constructor. Of course I would have to alter the source every upgrade. |
The next update will include your request, so you'll just need to change it once. I think that I would make the second parameter optional. If it's not given, the $table property won't be overriden. Therefore, you can set this property in your classes.
About your other post: I wasn't aware that you're new user. I thought you'd be an user that was annoyed about this requirement. I've posted a short feature request myself into the bug tracker:
http://pear.php.net/bugs/bug.php?id=13267
Thanks for your interest in DB_Table, and also for this idea. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
