Whoa, some of the stuff I'm going to do, but 4 spaces instead of tab? I could do that yeah, my editor can do that.
Ye gods...

I understand it's a religious issue for some, but it's really the way I work. We can add vim/emacs metadata to the files if necessary.
I would normally jump at the chance to volunteer for something like this, but I am so overloaded with projects right now that I would certainly let all of the rest of the team down. I am having a hard time keeping up with this thread right now as it is.
Forgive me for jumping in late - juggling work and commitments is a pain in the @$$. I'm catching up on the thread...
Contribute when you have time.
The reason I use mysql_data_seek() is because you need to rewind back to the beginning and it adds clearity thoughout what you are doing. It also works nicely with mysql_fetch_*() functions. However, it isn't something that I have thought of so it could optimize the iterator a little bit. If it could remove the two private variables then I'm all for it. However the valid() method would have to be optimized.
mysql_data_seek is essential for rewinding, I agree. The new way makes a bit more sense.
Normal MySQL can be used. MySQL3 anyone... MySQLi was designed specifically for 4.1.3 or better. I need to read the code, but presumably using MySQLi as the base assumption does not make it difficult to still work with MySQL or PgSQL libs. I think pg_fetch_result() has similar functionality for mysql_data_seek() (as a note-to-self).
What's MySQL3 (I get directed to mysqli...)? And I'm under the impression that mysql and mysqli are essentially the same in terms of the functions they provide (though mysqli also provides an OO interface to it)
Seems quite simple actually. The abstract class is pretty short. I feel put out without a PostgreSQL option though...Wink. Maybe I submit that.
That would be great. I specifically made the DB class with PostgreSQL in mind, but I don't have a working installation of the database lying around.
I think interfaces should have the "i" prefix. Abstracts can follow the same pattern as any generic parent class you might use. The "i" prefix is fairly common, but if you have another preference then so long as its consistent would still be fine.
I prefix it is. I'll update the code accordingly.
fetch() makes more sense IMO. next() does suggest an iteration over a fetching row data.
It's fetch() in the SVN now
Hmm..isn't there a svn prop called eol-style you can set to allow Windows/Unix line endings be made consistent regardless of the platform?
After checking:
http://svnbook.red-bean.com/nightly/en/ ... .eol-style , should be able to set this up (under Windows) in the TortoiseSVN config file - same as for the svn:keywords property setting described earlier.
*.php = svn:eol-style=LF
Think this will ensure those on Windows still commit files with Unix LF style new lines... Can also set it via the console client under Unix with the propset syntax.
Better yet, we could use svn:eol-style=native. I'll set that autoprop in my SVN installation and update the files in our repository accordingly.
I still need to review this thread - all 13 other pages of posts. Is there a list of required modules? At the very least I can add support for PostgreSQL and MSSQL on the DB side.
Take your time. I'm trying to summarize the entire theoretical discussion, and I'm only at page 6. Support for other DB wrappers would be nice. I'll have to add some docs on how to set optional unit tests with external resources (most of the times, we'll want to use stubs).
Do we actually want people to use the DB system? I thought it was just for testing. It could be a put off for other people to be forced to use our DB system when there are a bunch of others out there. I believe that there should be interfaces for which AuthTool's DB interfaces with the rest of the AuthTool as well as allow the other developers use their own DB abstraction classes.
There is an abstract DB class, if that's what you're looking for. There's no "forcing" to use the database, that's why I kept things as simple as possible, so that adapters would be easy to write.
Even so, there should be a 'lite' version that does not include the DB classes and only has the main AuthTools with the interfaces for the database.
Correct. I've been thinking about this too, and I'm not sure how we would automate the tagging process for "lite" versions.
One of the benefits of working in a group is that you are critique more often, which will improve the overall code. I will work on the iterator and improve it based on your suggestion. I do hope that it will be faster than it is now.
We don't have a benchmark to really say. I can set up a scaffold for that too, if necessary, but it's just DB abstraction.
I'm still not really sold on the foreach($result as $row) idea. If we decide to access rows that way, EVERYBODY should access rows that way, and we phase out the old fetch() method. Iterator, to me, is just an extra feature: while($row = $result->fetch()) still works perfectly fine (and is what most people are used to using).
I updated the Iterator and removed the index and max. It now only uses the mysql_fetch_* functions for moving forward and the valid() checks to see if the fetch functions returned false. It also allows you to specify whether you want to have NUM, ASSOC, or BOTH. Default is ASSOC, but it should be BOTH which is the default for mysql_fetch_array function.
Sounds good. The only drawback to this method is two copies of the row get made before it's returned back. The choice between ASSOC, NUM and BOTH, are, once again, a nice feature to have, but not absolutely necessary.
Edit: - I think it would be good to establish some standards here.
I didn't do a unit test or check for errors, but I'm to add the unit test for the isResource() and setFetch() (which needs a better name).
Have you set up the SimpleTest harness yet? (fortunantely, your update doesn't break any unit tests, but the unit test for MySQLIterator is kind of sparse).
Also, the class seems to logically be an offshoot of the MySQL class, so I might end up moving it.
Edit - Also, is there any point in code like...
I mean, it doesn't prevent undefined variable notices for popping up, etc, etc. I would at least set a default value to it (like false or array()) even if it's there for clarity.
Bug report! - I haven't verified it yet, but if we have both associative and numerical keys being returned, then we can't assume that a row with only one column will have a size = 1 (it will have a size = 2 for both)
Okay, cutting down on features - The MySQLIterator class has currently superceded the original Result class in terms of convenience functions. Since our goal isn't to provide a nice DB wrapper, we need to keep things as lean as possible. I propose we cut out some of the extra convenience, esp the one column auto-casting and the choose numeric or associative.