Yesterday I landed some code changes that will should show major performance improvements browsing large result lists.

Result lists together with filter and sorter options are managed by the class with the obvious name ZMResultList. So far, sorting and filtering is done in memory. While this allows for simple code to add sorting and filtering options, it also means that all items of a list need to be loaded first.

For small stores that is not really a big deal. There is a reasonable amount of caching going on in the service classes that provide access to the database. Also, with small lists the performance is as good a SQL based sorting, filtering and paging. Now for large catalogs this is not acceptable and in fact means that ZenMagick in its current form is unusable.

The way the new code works is to allow service classes (actually, any class that provides database access) to implement a new interface ZMSQLAware. When a result list is set up the code will check for implementation of this interface and if it exists, use the method(s) defined by that interface to do SQL based paging. This is similar to the way Zen Cart works now and in fact some of the code is based on that.

The next step will be to change the filter and sorter code to also be aware of SQL to have a full SQL based solution.

Today I’ve checked in support for sorters and filters! Right now, the only service to support this is ZMOrders (incl. a new order sorter (date and status) and filter (status).  The filter is not yet done properly since the code currently depends on request parameters. So among other things I’ll be reviewing all of that (for both sorters and filters) to make them request agnostic without having to write too much code.

After that is should be pretty easy to add support for other services, sorter and filter…