You can see an example of how I do this here: http://trac.symfony-project.org/browser/plugins/sfDoctrineMasterSlavePlugin/trunk/config/sfDoctrineMasterSlavePluginConfiguration.class.php#L24
Kris -- Kris Wallsmith | Release Manager [email protected] Portland, Oregon USA http://twitter.com/kriswallsmith On Jul 1, 2010, at 5:07 AM, Tom Boutell wrote: > 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 -- 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
