Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"orm:schema-tool:update --force" from within a PHAR archive leads to "No Metadata Classes to process" #5865

Closed
s0me0ther opened this issue Jun 9, 2016 · 3 comments
Assignees

Comments

@s0me0ther
Copy link

Stackoverflow Link
Github Example

PHP 5.6.3

I'm on the way to build a complete php application in a PHAR archive.

Therefore i want to programmatically build a sqlite database and several other files, if they dont exists in the root folder, where the phar archive is executed.

If i programmatically want to execute orm:schema-tool:update --force, it will perfect work, when triggered by console, or apache - if the script is NOT in a phar archive.

As soon as i execute the generated PHAR archive, which contains exactly the same code, the orm:schema-tool:update --force will output No Metadata Classes to process

If the file /Test/public/index.php is via apache handler or console triggered, and the sqlite database /database.sqlite does not exist, doctrine will create the database by the annotations of the Entity.

Start of output on line 53 in C:/xampp/htdocs/test.lh/Test/public/index.php

string(89) => Updating database schema...
Database schema updated successfully! "1" query was executed

If you trigger the generated phar, the same code is triggered, but the output then is:

Start of output on line 53 in phar://C:/xampp/htdocs/test.lh/test.phar/Test/public/index.php

   string(32) => No Metadata Classes to process.

How is it possible to let Doctrine generate the sqlite file by the annotations - by execute the PHAR archive?

@Ocramius
Copy link
Member

Ocramius commented Jun 9, 2016

Related? box-project/box2#85

Also: is the metadata driver pointing at the correct path?

@s0me0ther
Copy link
Author

s0me0ther commented Jun 9, 2016

Related? box-project/box2#85

I think not - if i look into the phar archive, all annotations are fully there, nothing is removed.

is the metadata driver pointing at the correct path?

Without PHAR execution its a normal absolute path, and correct.
With the PHAR execution its a Path into the PHAR archive phar://C:/xampp/htdocs/Project/generated/client.phar/src/Entity, but the path is correct.

if i scandir the phar uri from inside the phar, i get a full list of the entitiy files.
I can even open the EntityFiles and get there contents with file_get_contents - all annotations there, no problem in path or file itself.

@s0me0ther
Copy link
Author

s0me0ther commented Jun 9, 2016

I got an quickfix for this - but i have no clue if this is the right way, please have a short look:

https://github.com/sebka/test.lh/commit/b5c881431a624b51da226834810f236260a3c23f

I give the path in my application as following:

dirname(__DIR__) . implode('/', array(
    '' , 'Entity'
));

Which results in path phar://C:/xampp/htdocs/Project/generated/client.phar/src/Entity.

Then in the vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/AnnotationDriver.php there is a RegexIterator (Line 211) which gathers all files of the path.
As result there is a foreach of all gathered files @ Line 220.

The output of the Entity Filename is like:
phar://C:/xampp/htdocs/Project/generated/client.phar/src/Entity\Request.php

More bottom then he fetches all declared classes over get_declared_classes - fetches the reflection class of each declared class and $sourceFile = $rc->getFileName(); gets the source filename by the reflection class, which results in following:

phar://C:/xampp/htdocs/Project/generated/client.phar/src/Entity/Request.php

The source file will be compared via in_array with the source file from the regex iterator - both are NOT the same.

If i correct this issue with $sourceFile = str_replace('\\', '/', $sourceFile); the sqlite databse is generated and all works as expected.

So, this is a Windows / Unix Directory-Seperator problem..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants