3

I am working with a client that has some very large multi-select lists, large enough that they exceeded the 255 character limit of varchar. After some investigation I found a number of people that said they resolved this by changing the backend_type in the eav_attribute table from varchar to text. I did the same and after some testing things worked great.

Fast forward a few weeks. It was brought to my attention that the attribute that I did this to is no longer showing as a viable filter in layered navigation. After some investigation I've come to find that when the layered nav is built, it is unable to find products that would be applicable for this filter. If I changed the backend_type back to varchar and reindex, it starts working again. Change it to text and reindex, starts to fail.

I have reimported my product catalog with the backend_type set to text thinking that maybe it was just because of some weird ghost data. No luck. I have also tried updating the table using updateAttribute rather than just manually changing at the DB level thinking maybe there was some background processing that happened that I missed, no change.

So at this point I'm stuck in a situation where I need to store a lot of values in a multi-select array, in this case the largest is currently 341 characters, but I also need it to be usable as a layered nav filter which as near as I can tell does not work with text fields but will work with varchar.

Any suggestions?

1

I hope you already solved the issue, but I would approach this by using varchar type which not necessarily is 255 chars at max see http://dev.mysql.com/doc/refman/5.0/en/char.html

Otherwise yes the text backend type won't be indexed for layered navigation as it doesn't pass the checks in Mage_Catalog_Model_Resource_Eav_Attribute::isIndexable()

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.