Hi again. If I add an empty app/views/taglibs/application.dryml to the project it works fine if I add the hobo gem to the bundle.
Thanks a lot, I will continue working. I think next thing to do is to prepare a vanilla installation of Redmine with my current hobo-plugin development and upload it to github in order to have a vehicle for testing and sharing the improvements. Maybe the best option is to include the hobo as plugin (not a gem) in the Redmine installation so the hobo itself can be patched to add Redmine specific features. Thanks a lot. Tx. 2013/12/9 Txinto Vaz <[email protected]> > 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.
