Ah ha! And 'enableAllPluginsExcept' is deprecated as a backwards compatibility thing, so this is something we can get away with requiring. Thank you for your insight Kris.
Also, I just checked out http://trac.symfony-project.org/ticket/6926 which called for enableAllPluginsExcept to be removed. The resolution was to always sort in a known order. So a plugin developer who really wants to be compatible with enableAllPluginsExcept while still extending the schema of another plugin could choose a name that sorts last. Of course this is a brittle approach and it would be much smarter to state a requirement that enableAllPluginsExcept NOT be used. On Thu, Jul 1, 2010 at 3:32 AM, Kris Wallsmith <[email protected]> wrote: > 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 > -- 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
