Hi again. Thanks in advance for your help and feedback.
> About this problem, what happens if you create an empty > app/views/taglibs/application.dryml? I will make a try and keep you informed. The hobo_migrations should have to know about the changes introduced in plugin migration. I don't know what is exactly the mechanism to know how to calculate the migration, but probably it is comparing the result of the schema.rb with the sum of the migrations and, then, try to add/drop all the tables that are not present in both places. In my opinion and taking this example as basis, the sum of migrations need to include the migrations in the plugin subdirectories (plugin/n-plugin/db/migrate/*). This is difficult to do, because Redmine puts the plugins in plugins/ directory, but Rails puts the plugins in another place. So maybe this can be done setting an option like --include-plugin-migrations --plugin-directory-root=./plugins What do you think if we add an option to the generator like > "-never-drop" so it just ignores the "extra" tables? > Fantastic!!! This can be understood as a workaround or as the way to do it. In this second scenario, then the hobo g migration should be executed in different places: in rails root and in the myplugin subdirectory. In the first scenario (I think is more difficult to make it work) a hobo g migration in rails root will also calculate migrations for all plugins using hobo_fields. This sounds reasonable. I suppose you are referring to something like: > > hobo g resource event name:string -d plugins/superplugin > > So models are created into plugins/superplugin/app/ > models. Is this right? > Absolutely. And this can be the key to solve easily most of the abovementioned the problems. The hobo generators can probably create an intermediate file containing all the directories that include a migration, so it can be used later by hobo migration to know what to take into account. That's interesting, I wonder why it's trying to add a limit 4 for these > columns. I've searched Hobo's source and I didn't find anything on first > look. What database are you using? > > In this deployment I use MySQL, > A workaround could be to add an option "ignore-column-attributes" so the > generator just stops changing those columns. What do you think? > Fantastic again! Thanks a lot for your help. Tx. -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/hobousers. For more options, visit https://groups.google.com/groups/opt_out.
