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
