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
