I unconditionally subscribe to this method. I think this is pluggable ! Atti
On 22 sep, 18:08, nervo <[email protected]> wrote: > Since v1.1, symfony handles a way to distantly customize a db schema. > (seehttp://www.symfony-project.org/book/1_2/17-Extending-Symfony#chapter_... > "New in symfony 1.1"). > > This offers a great way to customize plugins, such as sfGuard. > Unfortunately, this is only available for propel, and not for > doctrine. > > A ticket with a patch has been openened (http://trac.symfony- > project.org/ticket/7042). > Also, i have seen that symfony 1.3 will handle such ability, but only > by overriding schemas, and not customizing them. I also doubt this > will be usable in plugins. > (seehttp://www.symfony-project.org/tutorial/1_3/en/upgrade > "Override Doctrine Plugin Schema"). > > Anyway. > In order to obtain a real pluggable system, i feel certain such a tool > has to be implemented. > And i found an another approach to achieve it. I'd like to discuss > about it. > > First, i did'nt find any way to interact with doctrine build tasks, > and make some kind of magic to handle custom schemas before it makes > its job. There is eventually a "command.pre_command" event we could > trap, but, we can't in a plugin > (seehttp://trac.symfony-project.org/ticket/7185). > > Second, we can not use the "config/doctrine" directory to store some > files describing custom schemas in it, as doctrine build tasks will > search ALL yml files in ALL subdirectories. > So, let's use "config/doctrine_custom" directory. > > Then, we use a config handler to handle all "config/doctrine_custom/ > schema.yml" (config handlers does not supports wildcards, so although > we can put any named yaml file in "config/doctrine", we have to choose > a single name in our case). > The handler then use the doctrine import & builder classes to generate > not records php code, but template php code classes definitions. This > php code appears in the cache, named > "config_doctrine_custom_schema.yml.php", which is include in every > request. > > Last operation, we create a doctrine template named "Customizable". > Every record acting as "Customizable" try to find a > "Doctrine_Template_Custom_Schema_[componentName]" (this class sit in > "config_doctrine_custom_schema.yml.php" i you followed me :) ) and > finally acted as it. > > Let's give an example. > > In a myUserPlugin, for instance, we just declare in our schema : > > myUser: > actAs: [Customizable] #<----- Thats' the point ! > columns: > name: ... > password: .... > > Then, in any other plugin, we create a "config/doctrine_custom/ > schema.yml" wich contains : > > myUser: > actAs: [Timestampable] > columns: > age: ... > size: .... > > These customs schemas are merged, and we generate a doctrine template > based on them, standing in cache, which is automatically associated to > our main record "myUser", as it act as "Customizable". > Now, "myUser" actas "Timestampable" and got two new columns, "age", > and "size". > > 'You see the point ? > > Well, this approach takes me days, but it's works. > You can download an alpha state plugin right there > :http://tao.nervo.net/nvDoctrineCustomSchemaPlugin.tar.gz > > But before going further, i'd like to have other developpers > opinions :) > Do you like it ? Have you thought about something better ? Something > simplier ? Something more powerfull ? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
