Hi Tom, The schema merge, which happens in sfDoctrineBaseTask::prepareSchemaFile(), loops through plugins in the order that they were enabled in ProjectConfiguration. If your plugin depends on sfDoctrineGuardPlugin in this way, it must be enabled after it.
Thanks, Kris -- Kris Wallsmith | Release Manager [email protected] Portland, Oregon USA http://twitter.com/kriswallsmith On Jun 30, 2010, at 4:53 PM, Tom Boutell wrote: > That makes sense for Propel, judging from the documentation, which > talks about the need for pluginName_schema.custom.yml files... sounds > like Propel should be able to tell very easily, then, which plugin > "owns" the table and therefore which one should contain Propel's > equivalent of PlugintableClassName.class.php. > > But Doctrine, as far as I can tell, can't possibly tell because the > schema.yml files of each plugin seem equally important. > > However, I do see a way the bug (?) could be fixed, and it seems > straightforward. > > On a doctrine:build --all-classes task invocation, Doctrine already > checks to see if plugintableClassName.class.php already exists, and > doesn't crush it if it does (because plugin developers are meant to > put code there and it shouldn't be overridden). > > But Doctrine only looks in the first plugin that happens to mention > that class in its schema before deciding it's OK to regenerate the > class. > > If Doctrine looked at all of the plugins, there wouldn't be a problem: > the developer of the original plugin would distribute > plugintableClassName, and on a doctrine:build --all-classes Doctrine > would check all of the plugins, spot plugintableClassName, and not > generate a duplicate, conflicting one. > > On Wed, Jun 30, 2010 at 7:25 PM, Richtermeister <[email protected]> wrote: >> Hey Tom, >> >> I'm using propel and I haven't tried to reproduce what you're talking >> about, >> but I have a plugin that extends the sfGuardPlugin model quite a bit, >> and all works great. >> I can then also extend the model once more on a project level. >> >> I have not tried extending one plugin twice via 2 other plugins, but I >> imagine that would work as well. >> >> One thing to note is that the merger of fields happens on a class >> name, not table name. >> So, in propel land, the phpName attribute must be the same for all >> entities to merge. >> >> Hope this helps, >> >> Daniel >> >> >> On Jun 30, 3:05 pm, Tom Boutell <[email protected]> wrote: >>> I'm taking this to devs because I'm not sure whether it's a bug or a >>> feature. >>> >>> The "extending Symfony" documentation says that schemas for plugins >>> and the application are merged, allowing the project to add columns >>> and also allowing several plugins to add columns to the same table: >>> >>> http://www.symfony-project.org/gentle-introduction/1_4/en/17-Extendin... >>> >>> However there is a problem when one attempts to use this feature with >>> two plugins. >>> >>> If plugin B originally defined: >>> >>> myclass: >>> columns: >>> text: >>> type: string(100) >>> >>> And plugin A wants to add a column: >>> >>> myclass: >>> columns: >>> age: >>> type: integer >>> >>> Then the schema merges just fine and you get a table with both columns. >>> However: >>> >>> ./symfony doctrine:build --all-classes >>> >>> Will generate PluginMyclass.class.php in plugin A, not plugin B, >>> because it happens to come first in alphabetical order (or maybe some >>> other platform dependent order, but the point is, it's bad and you >>> can't trust it not to happen). >>> >>> I think this means it is impossible for a separate plugin to >>> contribute columns to the sfGuardUser table without running the risk >>> of accidentally blocking all of the code that Jon Wage has written in >>> PluginsfGuardUser.class.php with an optional version. And in fact that >>> is what happens in my tests. >>> >>> Is this why Propel handles it differently - with >>> pluginName_schema.custom.yml files that can be distinguished from the >>> "main" schema? >>> >>> If this is a fact of life it is worth documenting explicitly in >>> Extending Symfony. The current language does not actually promise that >>> plugins can merge in additional fields into each other's tables, but >>> it's easy to miss this issue. >>> >>> For database normalization purposes it would be a Good Idea to support >>> this for bundles in Symfony 2.0, if that has not been addressed >>> already. >>> >>> For my own purposes I'll probably just recommend that developers add a >>> specific field to sfGuardUser at project level. >>> >>> -- >>> Tom Boutell >>> P'unk Avenue >>> 215 755 1330 >>> punkave.com >>> window.punkave.com >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
