Title: HyperDB (revisiting)
Last modified: September 23, 2020

---

# HyperDB (revisiting)

 *  Resolved [reverendcatch](https://wordpress.org/support/users/reverendcatch/)
 * (@reverendcatch)
 * [5 years, 8 months ago](https://wordpress.org/support/topic/hyperdb-revisiting/)
 * In reference to this, which is closed and (probably) should not be:
 * [https://wordpress.org/support/topic/incompatible-with-hyperdb-and-sql_calc_found_rows-deprecation/](https://wordpress.org/support/topic/incompatible-with-hyperdb-and-sql_calc_found_rows-deprecation/)
 * The problem here is two fold. HyperDB itself doesn’t check for anything between
   SELECT and SQL_CALC_ROWS_FOUND (in this case you use DISTINCT), which in itself
   may be an issue (I asked over there).
 * I have fixed this incompatibility by simply updating the preg in hyperDB and 
   modifying EM to look for the hyperdb flag ($wpdb->last_found_rows_result) set
   for automatic SELECT ROWS_FOUND() when using SQL_CALC_FOUND_ROWS. For example,
   in classes/em-events.php around line 215:
 * self::$num_rows_found = $wpdb->last_found_rows_result ? $wpdb->last_found_rows_result:
   $wpdb->get_var(‘SELECT FOUND_ROWS()’);
 * You could integrate easily with HyperDB in this sort of case, but you’d have 
   to drop the DISTINCT.
 * On the other hand, ya’ll should abandon this method (SQL_CALC_FOUND_ROWS) altogether
   as it’s deprecated by MySQL. Just run a second select query for COUNT(*) in this
   if/then statement rather than SELECT FOUND_ROWS() altogether — in the event pagination
   was even needed (I don’t think I’m even using it actually). I’d rather just mod
   one plugin rather than yours and HyperDB, but this fix is actually quicker in
   my case than trying to sort out your logic for post counting / pagination.
 * My solution sucks since it would require HyperDB to fix their own dealings with
   SQL_CALC_FOUND_ROWS not allowing statements between it and SELECT (which I think
   is likely faulty to begin with since it doesn’t follow valid SQL syntax, but 
   maybe there’s some sage-like reason). Alas, a plugin as popular as yours should
   probably not be outright incompatible with Automattic’s own DB extension they
   use widely on their own clustering solutions, but that’s a different matter.
 * Either case, I can’t use read-write split replication servers via HyperDB with
   Events Manager and that throws a gear in my cogs =P
 * It’s been 9 months since the aforementioned post, would be nice to get an update
   on the matter.

Viewing 1 replies (of 1 total)

 *  Plugin Support [angelo_nwl](https://wordpress.org/support/users/angelo_nwl/)
 * (@angelo_nwl)
 * [5 years, 8 months ago](https://wordpress.org/support/topic/hyperdb-revisiting/#post-13506767)
 * Hi,
 * This is already been escalated to the Devs, however, we don’t have any ETA yet
   as for the release of this version.

Viewing 1 replies (of 1 total)

The topic ‘HyperDB (revisiting)’ is closed to new replies.

 * ![](https://ps.w.org/events-manager/assets/icon-256x256.png?rev=3550347)
 * [Events Manager - Calendar, Bookings, Tickets, and more!](https://wordpress.org/plugins/events-manager/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/events-manager/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/events-manager/)
 * [Active Topics](https://wordpress.org/support/plugin/events-manager/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/events-manager/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/events-manager/reviews/)

 * 1 reply
 * 2 participants
 * Last reply from: [angelo_nwl](https://wordpress.org/support/users/angelo_nwl/)
 * Last activity: [5 years, 8 months ago](https://wordpress.org/support/topic/hyperdb-revisiting/#post-13506767)
 * Status: resolved