ZF-3033: _loadNorm() not working as designed.

Issue Type: Bug Created: 2008-04-03T07:26:16.000+0000 Last Updated: 2012-08-31T09:03:30.000+0000 Status: Open Fix version(s): Reporter: jim sloan (jsloan) Assignee: Alexander Veremyev (alexander) Tags: - Zend_Search_Lucene

Related issues: Attachments: - Zend_search_omnifind.tar.gz


In Zend_Search_Lucene_Index_SegmentInfo the private function _loadNorm($fieldNum) does not use the parameter passed in $fieldNum.

It loops over the $this->_fields array with a foreach that assigns a new value to $fieldNum.

        foreach ($this->_fields as $fieldNum => $fieldInfo) {
            if ($fieldInfo->isIndexed) {
                $this->_norms[$fieldNum] = $normfFile->readBytes($this->_docCount);

This is corrupting the $_norms array by adding empty elements to the array. I think that the intention is to load only the normalization data for the field being searched so the following line would suffice

$this->_norms[$fieldNum] = $normfFile->readBytes($this->_docCount);

I discovered this problem when using the Lucene collections created by the IBM Omnifind Yahoo! edition search engine. I posted more info here:…


Posted by Wil Sinclair (wil) on 2008-04-18T16:29:51.000+0000

Please evaluate and categorize/assign as necessary.

Posted by Alexander Veremyev (alexander) on 2008-07-18T10:50:55.000+0000

Great thanks for your report! I also looked through the details in your post at ZFForum.

The bug is in some other place..

<pre class="highlight">
foreach ($this->_fields as $fNum => $fieldInfo) {
    if ($fieldInfo->isIndexed) {
        $this->_norms[$fNum] = $normfFile->readBytes($this->_docCount);

Iterates through all fields and this is correct. I've changed $fieldNum variable name to $fNum, to increase code readability and make everyone not confused with two differed meaning of input variable $fieldNum and iterating variable $fNum

If index segment uses single norms file, then all norms are stored within .nrm file instead of set of files (.f0, .f1, .f3, ...) All norms are read at once at first request in this case.

That looks like .nrm file doesn't have enough data or Zend_Search_Lucene has some bug in some other place.

Could you attach your index to the issue for test purposes?

Posted by jim sloan (jsloan) on 2008-07-28T06:57:34.000+0000

The problem is still observed in 1.6RC1 so I have included the following for testing: + /IndexSource (HTML source) + /collections (Omnifind collection) + /library-1.6RC1 Search (Zend/Search) + /Search_Omnifind_index.php (demo searches for 'test' and returns 1 hit; this matches the result set when the same search is run on Omnifind)

I have patched /library-1.6RC1/Zend/Search/Lucene/Index/Segmentinfo.php so that the demo works with the Omnifind collection (line 951)

Posted by jim sloan (jsloan) on 2008-09-09T05:45:18.000+0000

Just installed 1.6.0 and this problem is not occurring!

Posted by Alexander Veremyev (alexander) on 2008-09-10T09:51:42.000+0000

OK Good.

There were some changes within Zend_Search_Lucene code before 1.6 release, so it could be fixed earlie.

Nevertheless, I keep issue opened since it has to be checked. Just decrease priority to Minor.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.