Till Klampaeckel [2008-08-28 20:58 UTC] Hey,
a couple questions, ...
1) In general, how do you see this package versus DB_Table?
2) Being Mysql-only, what would it take you to e.g. port your code to a MDB2_Table class instead? The class could serve the same purpose, but be compatible with different DB backends, etc..
3) If you don't like the idea of MDB2_Table, I'd still vote for a way to query different database backends (maybe through PDO). I'd also like to see an interface to inject a DB connection into your class vs. creating one "inside". Support for Mysqli wouldn't hurt either.
Generally, I like your idea a lot, since (at least IMHO) it's a pain to write all those calls again and again e.g. when you are writing an frontend to a database for administrative work.
Food for thought!
Cheers,
Till
Isaac Tewolde [2008-08-29 00:25 UTC] Excellent suggestions, there is no reason to depend solely on mysql. I think MDB2 is a very natural next step for this. I also like the idea of bringing in a database connection.
Both of these are not difficult to implement, the actual mysql calls are contained in a few methods that can be re-implemented to use MDB2.
Comparing with DB_table, there are differences both in implementation and the goal. This library is closer to the active record model. Another difference is that this library is further removed from the bare sql compared with DB_Table.
The idea behind this library is the "browser" model where one can sequentially step through and explore the data. It grew beyond this of course, but I would like to keep the interface simple and easy to use.
Thanks,
Isaac.
Philippe Jausions [2008-08-29 15:43 UTC] Several flaws / questions:
1) Missing support for multi-column primary key and sorting
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.
3) As Till already pointed at, MDB2 and / or PDO would be much better, especially the former when it comes to compatibility / portability.
4) No Iterator / IteratorAggregate implementation
5) You may want to update the examples. There are discrepancies between comments and method calls.
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.
8) No ArrayAccess implementation
9) Way far from PEAR's coding standards, but this is very minor at this stage of proposal given the items above.
Isaac Tewolde [2008-08-29 16:37 UTC] 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)?
David Coallier [2008-08-30 18:22 UTC] - Static SQL (Portability problems)
- Use MDB2 instead of your own db layer
- Of course the CS are far from PEAR's standard but as mentioned before, it's rather unimportant at this point (Even though it'd probably encourage people to review the proposal if it was a bit clearer)
- With previous point, of course you'll have to rename and restructure a lot of your code
|
