)
The biggest problem with SQL is that there is no standard, or at least there is supposed to be a standard but no one uses it. Every implementation has their own proprietary non-compatible versions of too many of the basic operations.
MODX Staff
If you care nothing about scalability or backward compatiblity while we continue to improve and change MODX, then no, this layer is not necessary. And falling back to native mysql_ functions is causing you to use multiple database connections on your page requests, one of the most expensive operations PHP has to perform, especially if you are using a remote database servers. You can still execute SQL, take advantage of PDO prepared statements, and utilize xPDO’s database result set caching capabilities without learning a thing about the xPDO abstraction layer or using objects. The choice of using PDO, which is a standard database access layer in PHP is absolutely on purpose and xPDO provides direct access to PDO methods with some additional features that make it even more useful. I would learn more about PDO before saying the DBAPI is a better option. And if you still don’t agree, you can use the dbapi plugin to add it back to MODX 2.1. BTW, the DBAPI uses PDO in MODX Revolution; it does not use the native mysql functions as did the DBAPI in Evolution.
But hear me out. How many people do you think will find themself in a situation where they go: "hmmmm our mysql server doesnt fit our needs, lets move to mssql!" to justify using ORM in current modx’s incarnation. I would bet that most people would choose to use DBAPI interacting with their databases directly, they do not want to take the time and effort to learn another abstraction layer if they do not have to, including me. Particularly for majority of their projects which involve simple database reads with a few writes. I am sure there are users out there which love and value what XPDo brings to the table, but I would bet that majority of users would not choose to go down this road.
For now, we have resorted to using native mysql functions in PHP, which means each snippet is storing database credentials - not good if anything changes. On evo this was great, you had access through DBAPI and could issue queries directly in your snippets.
You could almost think of this in terms of how easy you want to make your product to general users - the easier it is for most people to do most things, the greater chance you have of them adopting this CMS (sorry, framework!) over its competitors.
MODX Staff
<?php
$criteria = new xPDOCriteria($modx, "SELECT * FROM `mytable` WHERE `food` = ? ORDER BY `name` ASC", array('beer'), true);
if ($criteria->stmt && $criteria->stmt->execute()) {
while ($row= $criteria->stmt->fetch(PDO::FETCH_ASSOC)) {
echo $row['name'];
}
}
MODX Staff
modX does extend xPDO, but PDO is actually stored as a member variable on an instance of xPDO/modX. This is what allows the connect-on-demand features, and in the future there will be support for multiple connections to be configured (e.g. for read/write isolation on master/slave database configurations), so technically you would say...
So XPDO extends PDO and modX extends XPDO?
☆ A M B ☆