[PEPr] Comment on Database::table_browser
| From: | Isaac Tewolde | Date: | Fri, 29 Aug 2008 16:37:51 +0000 |
| Subject: | [PEPr] Comment on Database::table_browser | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-50681@lists.php.net to get a copy of this message | ||
Isaac Tewolde (http://pear.php.net/user/tewolde) has commented on the proposal for
Database::table_browser.
Comment:
Several flaws / questions:
1) Missing support for multi-column primary key and sorting
-I want a simple interface so I do not want to add this support just yet.
The same effect is achieved using filters anyway so it is not a hurdle.
Multiple key sorting will be added in the next version.
2) I'm not understanding the reason being the 2 steps: create instance
then select table. What is the benefit? I feel that being able to reuse the
same browser instance for 2 different tables will lead to confusion in user
code. A static method (factory, singleton,...) would be more appropriate.
-Agreed, excellent suggestion, I will implement this in this version.
3) As Till already pointed at, MDB2 and / or PDO would be much better,
especially the former when it comes to compatibility / portability.
-Yep. The next version will use MDB2.
4) No Iterator / IteratorAggregate implementation
-My objective was to use a browser model, where one creates a browser
object to see successive snapshots of data. I want to give the user the
ability to get these snapshots and not get in the way of what they do with
the results. The object is the browser, the results are transient.
5) You may want to update the examples. There are discrepancies between
comments and method calls.
-Will do, thanks.
6) Instead of referring to "category", using "column" sounds more generic,
and more related to an actual "table"
7) I would also reserve the term "item" when accessing by value, and "row"
when browsing.
-Terminology is a devilish problem. Agreed I will fix this issue on this
version.
8) No ArrayAccess implementation
-I am not sure I understand this...is this similar to your 4th point?
9) Way far from PEAR's coding standards, but this is very minor at this
stage of proposal given the items above.
-I will be adding more documentation, what would you say is the most
glaring difference(s)?
Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=570
--
Sent by PEPr, the automatic proposal system at http://pear.php.net