Feeling Lucky
?
[#26867] - [4.0] Don't use custom classes when loading database results
- Fixed in Code Base
- 11 Nov 2019
- Medium
- Build: 4.0-dev
- # 26867
- Diff
- SharkyKZ:j4/query/customClass
- Pending Hound Hound is busy sniffing around... Details
- Pending continuous-integration/drone/pr Build is pending Details
User tests: Successful: Unsuccessful:
Summary of Changes
With joomla-framework/database#201 removing support for loading results as custom classes on MySQLI, we should replace these uses in CMS.
Testing Instructions
Browse around frontend/backend. Create an article. Run Smart Search Indexer.
Expected result
Works like before.
Documentation Changes Required
No.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_finder com_installer com_menus Libraries |
| Labels |
Added:
?
|
||
wilsonge
- | Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-11-11 11:16:20 |
| Closed_By | ⇒ | wilsonge |
For clarity for those doing drive by reading, support isn't removed in the sense that a feature is completely gone. Rather, the database layer more accurately sets the right flags when calling the equivalent to
$db->loadObject(MyClass::class)and given the way the MySQLi driver is structured it can't 100% support nonstdClassobjects in all cases right now so it is throwing an Exception if trying to load an object as anything but astdClass(note the tradeoff right now is either force PHP with mysqlnd to be used for the MySQLi driver and then you get full object support or the way things are now where both libmysql and mysqlnd are supported but you lose some functionality of a few functions).Not to mention the behavior really should be discouraged if you are using a database abstraction layer (such as the
Joomla\DatabaseAPI or Doctrine's DBAL) because the different database extensions have different behaviors when you use their APIs to load class objects that might be inconsistent with the behavior you're expecting (i.e.ext/mysqlisets the properties before calling the constructor, which could collide with your constructor logic). If you're coding with a specific database extension then you can account for these extension specific behaviors in a more sane way, but that's asking for too much for an application that supports multiple database extensions.All of this is discussed in joomla-framework/database#199 as well for further context.