Share » Forums » Extensions » eZ Find » Bug in eZFind 2.3, objects +...

Bug in eZFind 2.3, objects + mainNode, ezsolr line 357

Bug in eZFind 2.3, objects + mainNode, ezsolr line 357

Thursday 07 October 2010 2:40:17 am - 5 replies

Author Message

Carlos Revillo

Thursday 07 October 2010 7:07:35 am

Hi. Probably is not the case, but one possible way to have these objects without nodes is the use of objectrelationbrowse extension. (don't know if the same goes for objectrelation list).

so, suppose you have an article class with a objectrelationbrowse attribute. if you want, you can add the option of adding new objects while you are filling all other attributes from the article. And you can also say that this objects will not be placed under any of the nodes of the content tree...

Don't know if this is the case, but yes, it's posible we can reach in something similar.

But, at the end, ezfind will return eZFindSearchResultsNodes, with their path and all of the usual ezcontentobjecttreenode objects. don't know if having those 'orphan' objects indexed can also leads in error while buidling the list of result nodes...

Christian Rößler

Thursday 07 October 2010 8:16:23 am

Thanks for your input Carlos,

well... we do not use the mentioned extension - but nice to know, thanks :-) May be useful sometime.

The site is a relatively new one, based on ezp 4.2.0, filled with approx 150.000 content-nodes and about 5000 users, all in about 15 languages. All the content-nodes have been imported in a 'import' folder. The customer now moves the imported articles from import-folder to the location he/she wants them to be.

In the process of moving, translating and adding related-objects to those articles, somehow the 'ghost-objects' appear. I just stumbled over them because the ezfindexcontent-cronjob was hardly quitting at one of such object which was in the 'pending_tasks' table about to be indexed using 'delayed indexing'.

 don't know if having those 'orphan' objects indexed can also leads in error while buidling the list of result nodes...

In eZFind 2.2 such ghost objects would never make it into ezfind. In eZF 2.3 the indexer crashes. So either way a search would never return such objects. So its no problem on this side. Returned nodes are all good.

Thanks again for your thoughts.

Chris

Hannover, Germany
eZ-Certified http://auth.ez.no/certification/verify/395613

Georg Franz

Wednesday 13 October 2010 3:58:35 am

Hi Chris,

as far as I know there are only two reasons why there is no mainnode:
a) the object isn't published (first version, first draft)
b) the object is deleted

But maybe your database is corrupted (failed transactions or something like that). You can check this with my "zombie check script":
http://issues.ez.no/IssueView.php?Id=16052&activeItem=2

Best wishes,

Georg.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Luca Realdi

Monday 21 March 2011 7:54:39 am

A trashed item loses the main_node_id. The cronjob ezfindexcontent verifies the content object, not if his node exsists.

In solr.php (ezFind 2.3.0) the main_node check - if ( !$mainNode ) - should be moved to the line 355 otherwise the $mainNodePathArray = $mainNode->attribute( 'path_array' ) generates error.

from

354 $mainNode = $contentObject->attribute( 'main_node' );
355 $mainNodePathArray = $mainNode->attribute( 'path_array' );
356 // initialize array of parent node path ids, needed for multivalued path field and subtree filters
357 $nodePathArray = array();
358 if ( !$mainNode )
359 {
360     eZDebug::writeError( 'Unable to fetch main node for object: ' . $contentObject->attribute( 'id' ), 'eZSolr::addObject()' );
361     return false;
362 }

to

354 $mainNode = $contentObject->attribute( 'main_node' );
355 if ( !$mainNode )
356 {
357     eZDebug::writeError( 'Unable to fetch main node for object: ' . $contentObject->attribute( 'id' ), 'eZSolr::addObject()' );
358     return false;
359 }
360 $mainNodePathArray = $mainNode->attribute( 'path_array' );
361 // initialize array of parent node path ids, needed for multivalued path field and subtree filters
362 $nodePathArray = array();

Bertrand Dunogier

Monday 21 March 2011 8:32:36 am

This is already fixed in ezfind/master:

https://github.com/ezsystems/ezfind/blob/master/search/plugins/ezsolr/ezsolr.php#L371

This will be part of the upcoming eZ Find 2.4 release: https://github.com/ezsystems/ezfind/commit/78edf846c84608fc80d784539cba18264216c05e.

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu