You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR solves two related issues with the use of a database schema on platforms (such as SQLite) that don't support schemas.
I discovered the issues when I generated the schema from my Doctrine entities on SQLite (for unit test purposes of my application) whereas my main application uses PostgreSQL.
This is one of my first PR on Doctrine, so sorry if I made some things in the wrong way and I'm open to discussion.
_First problem: table names dots are not converted in the ORM_
On a platform like SQLite, DBAL converts table names with dots (ie. a schema is declared) to double underscores.
However, the ORM doesn't do it, and persisting leads to an exception.
$myTable = new MyNamespace\Mytable();
$entityManager->persist($myTable);
$entityManager->flush();
This doesn't work in the current version of Doctrine. The table is created as myschema**mytable but entities are unsuccessfully saved in myschema.mytable.
_Second problem: table names with reserved keywords in a database schema are not correctly escaped_
When a table name is declared as myschema.order (or any other reserved keyword), only the reserved keyword part is escaped when creating the table, leading to the creation of a table name like myschema**order, which is invalid and therefore fails.
_How this PR solves the problem_
The classmetadata now stores in 2 separated properties the name of the table and the name of the schema. The schema property was partially implemented but I now make a full use of it.
When metadata is read (from Annotations, YAML, ...), if the table name has a dot (myschema.mytable), it's splitted into 2 parts, and myschema is saved in the schema table property, and mytable is saved in the name table property, instead of storing the whole myschema.mytable in the name table property.
This allows to do specific things about schemas everywhere in Doctrine, and not splitting again parts everywhere it's needed.
By the way, the schema property can now fully be used.
For instance, these 2 YAML configurations are valid and do the same thing:
This was something which was not finished to be implented since Doctrine 2.0.
The Default quote strategy now converts back the schema and table names to a unique table name, depending on the platform (e.g. myschema.mytable if the platform supports schemas, and myschema**mytable otherwise).
As a result, there is no problem anymore and entities can be persisted without getting any exception.
I added some unit tests for this (the same unit tests failed before of course).
There's however a slight tradeoff on performance, as the getTableName of the DefaultQuoteStrategy class adds some tests to return the correct table name.
Jira issue originally created by user @doctrinebot:
This issue is created automatically through a Github pull request on behalf of michaelperrin:
Url: #881
Message:
This PR solves two related issues with the use of a database schema on platforms (such as SQLite) that don't support schemas.
I discovered the issues when I generated the schema from my Doctrine entities on SQLite (for unit test purposes of my application) whereas my main application uses PostgreSQL.
This is one of my first PR on Doctrine, so sorry if I made some things in the wrong way and I'm open to discussion.
_First problem: table names dots are not converted in the ORM_
On a platform like SQLite, DBAL converts table names with dots (ie. a schema is declared) to double underscores.
However, the ORM doesn't do it, and persisting leads to an exception.
Example:
And then somewhere in the code:
This doesn't work in the current version of Doctrine. The table is created as
myschema**mytable
but entities are unsuccessfully saved inmyschema.mytable
._Second problem: table names with reserved keywords in a database schema are not correctly escaped_
When a table name is declared as
myschema.order
(or any other reserved keyword), only the reserved keyword part is escaped when creating the table, leading to the creation of a table name like myschema**order
, which is invalid and therefore fails._How this PR solves the problem_
The classmetadata now stores in 2 separated properties the name of the table and the name of the schema. The schema property was partially implemented but I now make a full use of it.
When metadata is read (from Annotations, YAML, ...), if the table name has a dot (
myschema.mytable
), it's splitted into 2 parts, andmyschema
is saved in theschema
table property, andmytable
is saved in thename
table property, instead of storing the wholemyschema.mytable
in thename
table property.This allows to do specific things about schemas everywhere in Doctrine, and not splitting again parts everywhere it's needed.
By the way, the
schema
property can now fully be used.For instance, these 2 YAML configurations are valid and do the same thing:
and:
This was something which was not finished to be implented since Doctrine 2.0.
The Default quote strategy now converts back the schema and table names to a unique table name, depending on the platform (e.g.
myschema.mytable
if the platform supports schemas, andmyschema**mytable
otherwise).As a result, there is no problem anymore and entities can be persisted without getting any exception.
I added some unit tests for this (the same unit tests failed before of course).
There's however a slight tradeoff on performance, as the
getTableName
of theDefaultQuoteStrategy
class adds some tests to return the correct table name.This solved these Doctrine issues: [DDC-2825](http://www.doctrine-project.org/jira/browse/[DDC-2825]%28http://www.doctrine-project.org/jira/browse/DDC-2825%29) and [DDC-2636](http://www.doctrine-project.org/jira/browse/[DDC-2636]%28http://www.doctrine-project.org/jira/browse/DDC-2636%29).
Again, this is one of my first PRs on Doctrine, so if there's anything wrong or if you have any question, feel free to comment this PR.
@Ocramius This PR is about what we talked about in [DDC-2825](http://www.doctrine-project.org/jira/browse/[DDC-2825]%28http://www.doctrine-project.org/jira/browse/DDC-2825%29)
The text was updated successfully, but these errors were encountered: