|
Yesterday I introduced the Iterator object. The purpose of
the Iterator object is to essentially make it pretty easy to work with sets of records.
Today I added four arguments that add a lot of power. If
you have, for example, an Iterator for a user, you can now pass from and count
arguments to getArray and getQuery. What’s this mean? It means
pagination I a piece of cake. Here’s a sample: <!--- get the first ten records from the Iterator -à <cfdump var=”#UserIterator.getQuery(1, 10#”
/> <!--- get the second ten records as an array -à <cfdump var=”#UserIterator.getArray(2, 10)#”
/> Why is this particularly cool? Well, the Iterator lets you
sort and filter the data as you need. When you actually request data it’s
cached in the object’s variables scope. So, let’s say you’ve
got 1000 users in your database. Creating the Iterator doesn’t do
anything with them. However, calling getQuery() will load them and cache
them. From that point forward you’re working with the dataset in
memory. Thus, getQuery(1, 10) just slices those records out of the variables
scope. Same with getArray. If you have your Iterator in a persistent scope
then you’re not going to have to run any additional queries. (Sorting
and filtering reset the query and it’s re-run.) This isn’t as good as only getting the specific rows
you want from the DB as needed, but it’s as good as I can do, given the
differences in implementations between database servers. Oh, that said, wouldn’t it be cool if you could just
get an Iterator for any given object easily? Well, you can. Now the
reactorFactor has a createIterator() method that works just like the other
create methods. The only difference is that it doesn’t generate
anything. (Ok, it will, if your records don’t exist.) Doug |
