Does xPDO automatically escape input?

So I was wondering if xPDO automatically escapes input, seeing as I haven’t been able to find anything concrete on Google.
If not, what do I use to escape with? For pure PDO it is PDO::prepare();
I am really looking forward to when we start using Revo and xPDO at my workplace, so I am just doing some information check up.

So if you have any other tid bits that might be valuable to know, please do post them along with any answers.

Quote from: MentalButcher at Jul 25, 2011, 07:25 AM

So I was wondering if xPDO automatically escapes input.

Yes.

For clarification, if you use prepared statements, yes it does filtering to prevent SQL injection or malformed input, though you can still bypass this in xPDO and this does not necessarily fully validate your any values that may be supplied via user input.

In xPDO, you can create queries and set values using various formats, some which bind the values as prepared statements, and some which just add SQL verbatim. For instance, this would use prepared statement bindings —

But adding an additional raw SQL statement would need variable input to be escaped using PDO::quote() (which is available, like all PDO methods, directly from xPDO) —

@openGeek, sweet, thanks a lot.
Might I add that I really appreciate the fast answers as well as a CMS that is developer friendly.

Just to hook into this & your "where" example Jason,

This *would* be escaped automatically right?

I took the time to read the php.net article about PDO and realised that, that is probably what I am going to use.

Firstly I am working in both Evo and Revo and would like something that works similar on both platforms without too much hassle. Secondly I am not the only person on this project, and for people that has been working with databases for several years, the xPDO syntax seems illogical.
I can see the point of xPDO and would love to use it, but as with most things technology, that will be a few years down the line.

I’ve seen old topics in which you can use xPDO in Evolution as well so it’s still possible

Sounds like valid reasoning to go with plain PDO if that’s what works best for your entire team though.

There is definitely no performance advantage to using PDO (or xPDO) in Evolution. It means on any page it is used you will have both the PDO connection and Evo’s mysql connection. Connecting to a database through the mysql extension or PDO is typically one of the most expensive operations you perform in a PHP request. Doing it twice for a single request is twice as expensive. Just some things to consider when using PDO/xPDO with Evolution.

@Mark H.
Yeah I tried to set it up, but I think I was missing some keys to make the OO layer of xPDO function properly, and I will have to avoid more tampering with the Evo source code and database than has already been done.
I think xPDO is a sweet technology, but as with most modern technology, I don’t think the world is ready for it yet, as in it would cost too much to implement properly.

@openGeek
Well the thing is that the built in $modx->db handler has never even been used on our Evo servers in the first place, and over making a regular mysql call, PDO takes only about one third of a regular mysql call. Then there is the fact that I need things to be auto escaped, which the db handlers query doesn’t do anyway.
My reason to choose PDO is because it is something I can get the hardcore DB crowd to use, it has auto escaping with the right commands (which I am going to tell people to use), it will gain a large performance boost over what we have now and I can prepare statements for others to use which will then be readily available.
As said the world isn’t perfect, if it was, we would be running Revolution and using xPDO.