[DoctrineBridge] Add common data fixtures loader #3328
Conversation
|
The reason to have a separate bundle for the ORM fixtures was that the ORM is released whereas the DataFixtures library is still in alpha versions. So we wanted to avoid having it in Symfony itself for the 2.0 release. It could maybe change now that we have the bundle in a separate repo. @beberlei what do you think about these suggestions ? And what is missing in DataFixtures to release it ? It has not changed recently except for the addition of the typehint and an update of the PHPCR purger |
| * fixtures objects that implement ContainerAwareInterface. | ||
| * | ||
| * Note: This class cannot be used without the Doctrine data fixtures extension, | ||
| * which is not listed as a required dependency for Symfony. |
There was a problem hiding this comment.
you should add it in the suggestions of the doctrine-bridge (and so of the symfony repo)
There was a problem hiding this comment.
I thought about that, but wasn't sure if it was too invasive :)
It makes sense, though.
There was a problem hiding this comment.
Making it less invasive is the reason why I suggested suggests and not recommends
| @@ -52,6 +52,9 @@ | |||
| "symfony/validator": "self.version", | |||
| "symfony/yaml": "self.version" | |||
| }, | |||
| "suggest": { | |||
| "doctrine/data-fixtures": "1.0.*" | |||
There was a problem hiding this comment.
DoctrineFixtureBundle's composer.json depends on version "*", but I know we probably don't want to do that. The data-fixtures package has two tags at the moment, v1.0.0-ALPHA1 and v1.0.0-ALPHA2. Will composer correctly resolve 1.0.* to the most recent tag even if the package's own composer.json file does not specify a version?
There was a problem hiding this comment.
well, composer will use the data coming from packagist and these one include the version guessed from the tag name by the VcsRepository (this is the only reason why you can omit it in a repo. For hand-defined packages, the version is mandatory)
And yeah, I think it should match the constraint. @Seldaek can you confirm ?
There was a problem hiding this comment.
and the reason why the bundle depends on * is simply that the bundle composer file has been written before tagging the releases (and it should be changed before tagging the bundle to avoid having a release with an * constraint).
There was a problem hiding this comment.
For the time being, 1.0.* matches 1.0.0-alpha1 yes. This will hopefully change soon though. Anyway this is the most correct thing to do right now I suppose.
|
The Symfony bridges provide integration between a third-party library and Symfony components. IIUC, this PR is only about Doctrine and as such it is not in the scope of the bridge. It should be done "somewhere" in the Doctrine namespace (what about common for instance?). |
|
@fabpot no it is not a Doctrine-only code. This extended loader is about integrating the Doctrine DataFixtures library with the DI component to allow fixtures to be container-aware (it does absolutely nothing else fancy btw). So this is in the scope of the bridge. |
|
I second @stof's point here. This class is specifically for loading fixtures into application with a service container. Likewise, that is why the base class it inherits is in the common data-fixtures library. Since this is common to both ORM and ODM, the most logical home for it would be DoctrineCommonBundle, and I believe that's what the bridge is :) |
|
@jmikola not even a DoctrimeCommonBundle IMO. This is not about integrating things with the fullstack framework but with one component |
Commits ------- c754f28 [DoctrineBridge] Rename data fixtures loader class af84805 [DoctrineBridge] Suggest doctrine/data-fixtures dependency e4243a1 [DoctrineBridge] Add common data fixtures loader Discussion ---------- [DoctrineBridge] Add common data fixtures loader Symfony does not depend on doctrine/data-fixtures, but having this class in the bridge would enable DoctrineMongoDBBundle (and possibly others) to load fixtures without requiring DoctrineFixturesBundle to be installed. Additionally, DoctrineFixturesBundle seems to only consist of this class and a command for loading ORM fixtures. With this in the bridge, we can possibly eliminate DoctrineFixturesBundle altogether by merging its command into DoctrineBundle. --------------------------------------------------------------------------- by stof at 2012-02-11T19:40:17Z The reason to have a separate bundle for the ORM fixtures was that the ORM is released whereas the DataFixtures library is still in alpha versions. So we wanted to avoid having it in Symfony itself for the 2.0 release. It could maybe change now that we have the bundle in a separate repo. The other solution could be to put all commands related to fixtures in DoctrineFixturesBundle but IIRC @beberlei rejected a PR trying to make the same command work for ORM and PHPCR. @beberlei what do you think about these suggestions ? And what is missing in DataFixtures to release it ? It has not changed recently except for the addition of the typehint and an update of the PHPCR purger --------------------------------------------------------------------------- by fabpot at 2012-02-14T23:30:23Z The Symfony bridges provide integration between a third-party library and Symfony components. IIUC, this PR is only about Doctrine and as such it is not in the scope of the bridge. It should be done "somewhere" in the Doctrine namespace (what about common for instance?). --------------------------------------------------------------------------- by stof at 2012-02-14T23:34:19Z @fabpot no it is not a Doctrine-only code. This extended loader is about integrating the Doctrine DataFixtures library with the DI component to allow fixtures to be container-aware (it does absolutely nothing else fancy btw). So this *is* in the scope of the bridge. --------------------------------------------------------------------------- by jmikola at 2012-02-15T00:40:12Z I second @stof's point here. This class is specifically for loading fixtures into application with a service container. Likewise, that is why the base class it inherits is in the common data-fixtures library. Since this is common to both ORM and ODM, the most logical home for it would be DoctrineCommonBundle, and I believe that's what the bridge is :) --------------------------------------------------------------------------- by stof at 2012-02-15T01:53:17Z @jmikola not even a DoctrimeCommonBundle IMO. This is not about integrating things with the fullstack framework but with one component
Commits ------- 48a288e [DoctrineBridge] Add tests for data fixture ContainerAwareLoader Discussion ---------- [DoctrineBridge] Add tests for data fixture ContainerAwareLoader ``` Bug fix: no Feature addition: yes Backwards compatibility break: no Symfony2 tests pass: yes Fixes the following tickets: #3328 (PR was missing this test) Todo: - ``` The test is skipped unless the optional `doctrine/data-fixtures` is available. I confirmed that it passes with it installed. Once this is merged, the DoctrineFixturesBundle will contain nothing more than a console command, which can be merged into DoctrineBundle.
Symfony does not depend on doctrine/data-fixtures, but having this class in the bridge would enable DoctrineMongoDBBundle (and possibly others) to load fixtures without requiring DoctrineFixturesBundle to be installed.
Additionally, DoctrineFixturesBundle seems to only consist of this class and a command for loading ORM fixtures. With this in the bridge, we can possibly eliminate DoctrineFixturesBundle altogether by merging its command into DoctrineBundle.