I want to display categories on the start page. I list them using the $oxcmp_categories variable. The problem is that not all database fields of the categories are loaded. I don’t know if this is some performace stuff or what, but the thing is I cannot get the thumb url for the categories. The same situation is in the category_tree.tpl.
Curiously inside list.tpl the thumb image of the category is loaded. I checked how categories are loaded in the respective views, but couldn’t find any special stuff that would make all the values load for list.tpl but not for category_view.tpl.
I had a thorough look at the code, and I see that you are loading some kind of array from the cache (oxpec_fieldnames_oxcategories_allviews_i18n.txt), that contains which fields are to be loaded and which don’t. I don’t see how this array is created, and why do you need to cache such information.
Tnx for your help!
Hi,
the object is not everywhere loaded; you need to get the needed information with a getter maybe. Please have a look at
http://docu.oxid-esales.com/CE/sourcecodedocumentation/4.4.5.31315/
and watch out for “getThumbName” (<-- not sure if this is the right one)
Regards
There is no getter for the thumb property in oxcategory.php. But anyway all the getters are just delegating to the database accessor:
public function getIconUrl()
{
return $this->getConfig()->getIconUrl( 'icon/'.$this->oxcategories__oxicon->value );
}
If oxcategories_oxicon wasn’t initialized then this getter wouldn’t be working also. My problem is that oxcategories__oxthumb->value is null.
Tnx, this info was most useful! I can see now how to solve my problem (add the oxthumb field to the sql), but I still don’t get how this system works.
-
Why is it, that if lazy loading is disabled then not all properties are loaded (I would expect the other way around)
-
How to influence which properties are loaded if lazy loading is disabled, aside from manually adding them to the query (this is actually my original question)?
-
If lazy loading is disabled (as it is by default), does the whole category tree get loaded on each page rendering? Or are the subcategories loaded lazily?
Yes you can add the field to the sql also.
- Why is it, that if lazy loading is disabled then not all properties are loaded (I would expect the other way around)
Yes i think it is the other way round: when disabled all fields are loaded, when enabled only oxid is loaded, if you use the standard “load()”-mechanism. But in this case deliberately only certain fields are loaded, and only with lazy loading turned on fields can be fetched afterwards.
- How to influence which properties are loaded if lazy loading is disabled, aside from manually adding them to the query (this is actually my original question)?
I think this is the only way (manually).
- If lazy loading is disabled (as it is by default), does the whole category tree get loaded on each page rendering? Or are the subcategories loaded lazily?
AFAIK lazy loading works only for single objects, not for the cat-tree.
I have done a little debugging and it seems that all categories are loaded on each page load. This is the sql that is executed:
select oxcategories.oxid as oxid, oxcategories.oxactive_2 as oxactive, oxcategories.oxhidden as oxhidden, oxcategories.oxparentid as oxparentid, oxcategories.oxdefsort as oxdefsort, oxcategories.oxdefsortmode as oxdefsortmode, oxcategories.oxleft as oxleft, oxcategories.oxright as oxright, oxcategories.oxrootid as oxrootid, oxcategories.oxsort as oxsort, oxcategories.oxtitle_2 as oxtitle, oxcategories.oxdesc_2 as oxdesc, oxcategories.oxpricefrom as oxpricefrom, oxcategories.oxpriceto as oxpriceto, oxcategories.oxicon as oxicon, oxcategories.oxextlink as oxextlink, oxcategories.oxthumb as oxthumb ,not oxcategories.oxactive_2 as oxppremove from oxcategories where 1 order by oxrootid desc, oxleft desc
I think that category handling could be improved in Oxid for two reasons:
-
The whole tree is never displayed on the page, so this is loading a lot of data into memory for no reason.
-
As you say in your blog post lazy loading in Oxid means that the loading of any field generates a new sql which is criminally inefficient. This means that the price of lazily loading the subcategories is to lazily load all properties, which would generate an sql statement per property.
I primarily use Java for development, and coming from that background this approach seems very inefficient for me (either loading every property lazily or always loading the whole tree). The Java ORM mappers (notably Hibernate) do a cross between these two techniques: Always load simple properties eagerly (because loading of some unneeded values into memory is less costly then an sql query in 90% of cases), but load associations lazily, because especially with tree structures that can save a lot of memory.
Of course this approach is not always the best (if the records have huge amount of columns or some columns contain a lot of data, also if the whole tree IS needed then doing it in 1 sql is more efficient then lazy loading), but particularly for the Oxid category tree it most certainly is - there are just a few properties in a category so it makes no sense in picking which to load or not, and whole tree is never displayed on the page (opening of a category generates a new page rendering, and only one category can be open).
I hope that this assessment is accurate and helps you improve Oxid performance.