Update search index on tag delete/name change.

[luku]

This is solution for issue #764
It also adds possibility to update search index (instead of always creating new from scratch). The update can be accomplished in 2 ways:

1. using SQL (by selecting or aliasing record_type, record_id columns)

Zend_Registry::get('bootstrap')->getResource('jobs')
    ->sendLongRunning('Job_SearchTextIndex', array(
        'sql' => "SELECT record_type, record_id FROM table WHERE x=y"
    ));

2. using array (maps record types and ids to update)

Zend_Registry::get('bootstrap')->getResource('jobs')
    ->sendLongRunning('Job_SearchTextIndex', array(
        'records' => array(
            'Item' => array(1,2,3,4, ...),
            'Collection' => array(1,2,3,4, ...),
        )
    ));

@zerocrates I know you said it is too big update for version 2.5, but I think it's really practical to be able to update the search index via core job and it doesn't feel like a dangerous update or complicated one.

[luku]

Well, I see another use case for search index update where none of suggested approaches really works; When adding new record types that should be searchable in admin/settings/edit-search, it should update/add this new record type into search index. What would be best way then? Using array as previously, but instead of array of ids it would accept Boolean true and index all records for those record types:

Zend_Registry::get('bootstrap')->getResource('jobs')
    ->sendLongRunning('Job_SearchTextIndex', array(
        'records' => array(
            'Item' => true,
            'Collection' => true,
        )
    ));

?? Any ideas?

[luku]

I noticed the search index is not updated on tag delete either, so I added possibility for it as well, but 2 concerns popped up...

1. When deleting, it's not possible to use SQL. Only map of record types and ids is usable. So I wonder if we should change the data type for args column into mediumtext or longtext?
2. When doing batch-delete of tags (via some plugin), the search index update may be very CPU/memory intensive and not really optimal. Search indexing of same item with 3 tags being deleted will run 3 times, instead of once. Every deleted tag will spawn new parallel process. Finally, even DB table processes may get filled quickly and take lot of space.