pdo_sqlite: DROP TABLE not working with dots

[miguelgf]

I've trying to create a DB with names as aaa.bbb with SQLite. With the create table everything works fine, it just change the "." char to "__" here.

But this behaviour is not good when trying to delete the table, because to get the name of the table to delete doesn't follow the same rules.

I'm not sure if the bugs belongs here or to dotrine/ORM, because the getSchemaFromMetadata is the funcion that doesn't get the correct name from SQLite table.

Table name: aaa.bbb is created as aaa_bbb
Table name returned by DropSchemaSqlColector::getSchemaFromMetadata: aaa.bbb

When it tries to check if exists to be deleted $schema->hasTable($table->getName()) is always false. So it's possible to create a table but never delete it.

The high level code I'm using where I see all this is:

$em = $kernel->getContainer()->get('doctrine')->getManager();
$schemaTool = new SchemaTool($em);
$metadata = $em->getMetadataFactory()->getAllMetadata();

$schemaTool->dropSchema($metadata);
$schemaTool->createSchema($metadata);

The entity should be name with a dot:

 * @ORM\Table(name="aaa.bbb")

I'm not sure how to create a test case that fails to show the problem.

[Ocramius]

I updated the links with their absolute references (don't link directly from master, since it's a moving target).

@infinit89 the schema diff is used within the schema tool of ORM, so you can probably dump the diff and we can write a test starting from there?

[miguelgf]

I'm not sure how to get to compare the schema, I'll try to provide more info of how I'm reproducing this error.

The example entity:

/**
 * @ORM\Table(name="aaa.bbb")
 * @ORM\Entity()
 */
class Aaabbb
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    private $id;
}

Using SQLite as Driver, I do:

$kernel = static::createKernel();
$kernel->boot();
$em = $kernel->getContainer()->get('doctrine')->getManager();
$schemaTool = new SchemaTool($em);
$metadata = $em->getMetadataFactory()->getAllMetadata();

And then I expect the given results, being the first correct:

$schemaTool->createSchema($metadata);

Inside createSchema, a dump() of $createSchemaSql = $this->getCreateSchemaSql($classes); shows:

array:1 [
  0 => "CREATE TABLE aaa__bbb (id INTEGER NOT NULL, PRIMARY KEY(id))"
]

This is good! perfect, but just after that (with the create table executed) I do:

$schemaTool->dropSchema($metadata);

And inside dropSchema, a dump of $dropSchemaSql = $this->getDropSchemaSQL($classes); shows:

[]

And the expected result should be:

array:1 [
  0 => "DROP TABLE aaa__bbb"
]

Let me know how to provide more info or be more helpful.

[Ocramius]

Bug and expected output seem clear, but still need to be presented as isolated test case in order to be inspected.

Is the DropSchemaSqlCollector containing any tables during getDropSchemaSQL execution?

I'm thinking that the bug may be here

[miguelgf]

Sorry I didn't link that part, the bug is there, where you point, Indeed in first comment I copied that part of code but forgot to link it.

Replying your question: No, the DropSchemaSqlCollector does not contain any tables during execution here.

[miguelgf]

Well, I've fork the doctrine2 project and made a test expecting to fail, surprising it didn't fail and passed.

doctrine/orm@2e0ee58

Tomorrow at work I will see why there the result was different and copy this test (because I saw the error at work).

Still if the test is valid I can make a pull request of the test case.

[deeky666]

@infinit89 as far as I can see the schema support for SQLite is incomplete and not working for your case. The schema comparator simply can't compare namespaced database objects because reverse engineering (__ -> .) is not implemented and I don't see how we possibly could do that safely. One could have identifiers in ORM like foo__bar which would get reverse engineered as foo.bar (if implemented. Schema support in SQLite is emulated and IMO we should not have tried to implement it because it simply can't work for reverse engineering.
Still, if you have any ideas, they are very welcome.

[deeky666]

We would need some kind of reserved characters for identifiers in ORM to have a separator that we can use for this purpose. But that is not possible in 2.x I am afraid.