perrin at elem.com
Mon Aug 28 04:56:45 BST 2006
Tom Metro wrote:
> One of the complication I ran into when implementing this was the
> sorting. Objects in the iterator's list are not inflated, so sorting on
> anything but the ID requires first inflating the objects.
That could be very inefficient if you don't need all of those fields.
It's much better to sort with SQL. Personally, I avoid
Class::DBI::Iterator completely, since it's always worse (for
performance) than just loading all of the records if you actually need
to use all the records returned by it (and if you don't, you shouldn't
be searching for them).
I added support for ORDER BY and LIMIT by adding a couple of small
patches from this list to the _do_search method in my base class. If
you're interested, I'll post it here. That, combined with custom SQL
where needed, allows me to work with sets efficiently and avoid Iterator.
> What I'm less sure about is how CDBI handles modification to
> collections. If I access $parent->child and get back a sorted list from
> the database, then call $parent->add_to_child() to add another record to
> the list, then call $parent->child again, does the newly added record
> get returned in the collection?
> Is it in the correct sort position?
> CDBI hit the database every time a has_many() method is called, or does
> it cache collections also?
Class::DBI doesn't cache anything.
More information about the ClassDBI