original_string: public static function getRankingQueryLimit()
      {
          $configGeneral = Config::getInstance()->General;
          $configLimit = $configGeneral['archiving_ranking_query_row_limit'];
          $limit = $configLimit == 0 ? 0 : max(
              $configLimit,
              $configGeneral['datatable_archiving_maximum_rows_actions'],
              $configGeneral['datatable_archiving_maximum_rows_subtable_actions']
          );
  
          // FIXME: This is a quick fix for #3482. The actual cause of the bug is that
          // the site search & performance metrics additions to
          // ArchivingHelper::updateActionsTableWithRowQuery expect every
          // row to have 'type' data, but not all of the SQL queries that are run w/o
          // ranking query join on the log_action table and thus do not select the
          // log_action.type column.
          //
          // NOTES: Archiving logic can be generalized as follows:
          // 0) Do SQL query over log_link_visit_action & join on log_action to select
          //    some metrics (like visits, hits, etc.)
          // 1) For each row, cache the action row & metrics. (This is done by
          //    updateActionsTableWithRowQuery for result set rows that have
          //    name & type columns.)
          // 2) Do other SQL queries for metrics we can't put in the first query (like
          //    entry visits, exit vists, etc.) w/o joining log_action.
          // 3) For each row, find the cached row by idaction & add the new metrics to
          //    it. (This is done by updateActionsTableWithRowQuery for result set rows
          //    that DO NOT have name & type columns.)
          //
          // The site search & performance metrics additions expect a 'type' all the time
          // which breaks the original pre-rankingquery logic. Ranking query requires a
          // join, so the bug is only seen when ranking query is disabled.
          if ($limit === 0) {
              $limit = 100000;
          }
          return $limit;
  
      }
code: public static function getRankingQueryLimit()
      {
          $configGeneral = Config::getInstance()->General;
          $configLimit = $configGeneral['archiving_ranking_query_row_limit'];
          $limit = $configLimit == 0 ? 0 : max(
              $configLimit,
              $configGeneral['datatable_archiving_maximum_rows_actions'],
              $configGeneral['datatable_archiving_maximum_rows_subtable_actions']
          );
  
          // FIXME: This is a quick fix for #3482. The actual cause of the bug is that
          // the site search & performance metrics additions to
          // ArchivingHelper::updateActionsTableWithRowQuery expect every
          // row to have 'type' data, but not all of the SQL queries that are run w/o
          // ranking query join on the log_action table and thus do not select the
          // log_action.type column.
          //
          // NOTES: Archiving logic can be generalized as follows:
          // 0) Do SQL query over log_link_visit_action & join on log_action to select
          //    some metrics (like visits, hits, etc.)
          // 1) For each row, cache the action row & metrics. (This is done by
          //    updateActionsTableWithRowQuery for result set rows that have
          //    name & type columns.)
          // 2) Do other SQL queries for metrics we can't put in the first query (like
          //    entry visits, exit vists, etc.) w/o joining log_action.
          // 3) For each row, find the cached row by idaction & add the new metrics to
          //    it. (This is done by updateActionsTableWithRowQuery for result set rows
          //    that DO NOT have name & type columns.)
          //
          // The site search & performance metrics additions expect a 'type' all the time
          // which breaks the original pre-rankingquery logic. Ranking query requires a
          // join, so the bug is only seen when ranking query is disabled.
          if ($limit === 0) {
              $limit = 100000;
          }
          return $limit;
  
      }
code_tokens: public static function getRankingQueryLimit ( ) { $ configGeneral = Config :: getInstance ( ) -> General ; $ configLimit = $ configGeneral [ 'archiving_ranking_query_row_limit' ] ; $ limit = $ configLimit == 0 ? 0 : max ( $ configLimit , $ configGeneral [ 'datatable_archiving_maximum_rows_actions' ] , $ configGeneral [ 'datatable_archiving_maximum_rows_subtable_actions' ] ) ; // FIXME: This is a quick fix for #3482. The actual cause of the bug is that // the site search & performance metrics additions to // ArchivingHelper::updateActionsTableWithRowQuery expect every // row to have 'type' data, but not all of the SQL queries that are run w/o // ranking query join on the log_action table and thus do not select the // log_action.type column. // // NOTES: Archiving logic can be generalized as follows: // 0) Do SQL query over log_link_visit_action & join on log_action to select //    some metrics (like visits, hits, etc.) // 1) For each row, cache the action row & metrics. (This is done by //    updateActionsTableWithRowQuery for result set rows that have //    name & type columns.) // 2) Do other SQL queries for metrics we can't put in the first query (like //    entry visits, exit vists, etc.) w/o joining log_action. // 3) For each row, find the cached row by idaction & add the new metrics to //    it. (This is done by updateActionsTableWithRowQuery for result set rows //    that DO NOT have name & type columns.) // // The site search & performance metrics additions expect a 'type' all the time // which breaks the original pre-rankingquery logic. Ranking query requires a // join, so the bug is only seen when ranking query is disabled. if ( $ limit === 0 ) { $ limit = 100000 ; } return $ limit ; }
docstring: Returns the limit to use with RankingQuery for this plugin.
  
  @return int
docstring_tokens: Returns the limit to use with RankingQuery for this plugin .