This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/338

Message:

This fixes a bug introduced in PR #302 where the foreign table name did not get properly quoted in some circumstances.

This issue is created automatically through a Github pull request on behalf of Tim-Erwin:

Url: https://github.com/doctrine/dbal/pull/330

Message:

This adds deep clone support to the DBAL QueryBuilder. I just realized, there is already a pending pull request for this, however, this one already incorporates the suggestions found in the former.

This issue is created automatically through a Github pull request on behalf of kinncj:

Url: https://github.com/doctrine/dbal/pull/334

Message:

This issue is created automatically through a Github pull request on behalf of kinncj:

Url: https://github.com/doctrine/dbal/pull/335

Message:

As talked with Blanco.
Quoting table name to avoid errors with:
```sql
SELECT * FROM order;
```
it was possible doing
```php
ORM\Table(name="`order`");
```
But if I change the database, I should change all my entities to the "new quotes"

this way, we can avoid this errors in a "transparent" way.

This issue is created automatically through a Github pull request on behalf of javierseixas:

Url: https://github.com/doctrine/dbal/pull/337

Message:

Hi,

I was trying to use the findBy method from the repository, where some of the criteria data were negative floats values. I didn't get any results, though I had coincidental records in the BD with that criteria.

After searching I found this issue: http://stackoverflow.com/questions/8300208/php-pdo-prepare-negatives-become-positive

So, it seemed the problem was caused for the same reason. I've added the getBindingType() returning the PDO::PARAM_INT constant and now my findBy is returning the results correctly.

We are using prepared statements and parsing on top at the moment to implement things like array param quoting and such.

We should evaluate if it makes sense to introduce a strategy for preparing/parsing queries and make sprintf() usage a default in 3.0 instead of using prepared statements. At least for MySQL the PHP Driver guys are arguing for this kind of processing for years.

This issue is created automatically through a Github pull request on behalf of naroga:

Url: https://github.com/doctrine/dbal/pull/336

Message:

'0' was the previous hardcoded error code. I'm just forwarding whatever SQL Error code might occur during a query.

Previous to this fix, we'd have to check for whatever Exception was thrown before DBALException in order to get the error code.

Useful when trying to come up with user-friendly error messages.

This issue is created automatically through a Github pull request on behalf of deeky666:

Url: https://github.com/doctrine/dbal/pull/302

Message:

This PR introduces a real solution for the issues discussed in DBAL-374(http://www.doctrine-project.org/jira/browse/DBAL-374).
It adds the possibility to retrieve quoted column names from <code>Index</code> and <code>ForeignKeyConstraint</code> assets if it is necessary (e.g. column name is a keyword reserved by the platform).
In general column names are wrapped into an abstraction class <code>Identifier</code> which inherits from <code>AbstractAsset</code> inside <code>Index</code> and <code>ForeignKeyConstraint</code>. This allows to get a quoted representation of each column name via the <code>AbstractAsset::getQuotedName</code>.
All platforms are updated to make use of the new functionality.

This issue is created automatically through a Github pull request on behalf of pmen:

Url: https://github.com/doctrine/dbal/pull/327

Message:

In the documentation of the the ResultStatement::fetch() function says that we should use the Query::HYDRATE_* constants but that constant does not exist at least not in 2.3.4.

Should I just use PDO::FETCH_BOTH? But if I change the driver to sqlite or whatever is it going to work well?