Migrations failing on add_field_groups_klass_name.rb -> Label cannot be emtpy

11 views
Skip to first unread message

Michael Starke

unread,
Apr 22, 2012, 5:43:20 AM4/22/12
to fat-free-...@googlegroups.com
Hello there,

I'm trying hard to install FFCRM as a Rails engine. I did not want to rely on your git repo so i went straight for the pure-gem installation by adding the ffcrm gem (and the mysql gem) in the gem file and nothing more.

My gem file:
source 'https://rubygems.org'

gem "fat_free_crm", "~> 0.11.1"
gem "mysql", "~> 2.8.1"

I use the mysql gem instead of mysql2 because we use  a puppet infrastructure it's set up to use mysql across the board.
My test with mysql2 did yield the same migration error.

The first thing I'd like to note is, that the tutorial on creating a bare Rails app and using FFCRM as a Rails engine lacks a critical part in environment/application.rb
Railties.engines.each do |engine|
config.paths['db/migrate'] += engine.paths['db/migrate'].existent
end
If this is not added, no migrations will her run by rake db:migrate.

After adding this, the migration fails on field_groups_klass_name.rb with the error, that "Label cannot be empty" or left blank?
The db states, that label in the filed_groups has can be empty set to true and default to NULL.

Is this a mysql problem? Anyone else having this issue?

I really would like to get this thin off and running without having to repack a own gem and distribute that to my machines.
The git->pull method is unreliably as the reopo is likely to change so I may run into future problems trying to reuse the pupet setup procedure for a new FFCRM instance.

--
Michael

ben tillman

unread,
Apr 23, 2012, 6:54:41 PM4/23/12
to fat-free-...@googlegroups.com
Hi Michael,

Good work figuring out the migration trick I will update the
installation instructions to reflect the need for the addition to
application.rb. I believe we used mysql2 as it has better support for
utf8 fields under rails 3 but if that is not an issue for you then
from memory mysql gem should still work.

I find it a little strange that it fails at that point in the
migration because the default FieldGroup label for each class should
be set to 'Custom Fields' can you run `rake db:migrate --trace` to see
if it is failing on line 7 of the migration?

Regards
Ben Tillman

> --
> You received this message because you are subscribed to the Google Groups
> "Fat Free CRM Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/fat-free-crm-users/-/THlnFclzWgYJ.
> To post to this group, send email to fat-free-...@googlegroups.com.
> To unsubscribe from this group, send email to
> fat-free-crm-us...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fat-free-crm-users?hl=en.

Michael Starke

unread,
Apr 24, 2012, 7:52:57 PM4/24/12
to fat-free-...@googlegroups.com
Hello again,

Well - something's off.

The migrations fails the first time at field_groups_klass_name.rb
But the db is altered in the right way, so the next time you run the migrations, it says it has a duplicate field.
I added the next migrations step by hand (by adding the next id in the schema_migrations table) and it went though. Strange.

But the app doesn't start quite so fast, there's still something wrong =)
You also have to remove the /app folder, otherwise this gets parsed and bad things happen (as in Internal Server Error)
After having cleaned the new rails app to look more like your default project it ran.

Everything runs as a rails engine and works (so far, I have not tested this for so long, just a couple of minutes)
What strikes me as odd it the failing validation but a successful alteration fo the database.

Hope this helps. So you need to alter the guide a bit more by adding the
> rm -rf /path/to/application/app

Hope this info is useful to anyone.
Michael

Michael Starke

unread,
Apr 24, 2012, 7:26:17 PM4/24/12
to fat-free-...@googlegroups.com
Hi Ben,

I tried using the Rails gem as a starting point by unpacking the gem and then using my simple gemfile, and voila the migrations worked.
I have no clue why it's working in this scenario since I'm a complete rails-noob.

My goal is still to use the gem as RailsEngine so on we go with the painful bug hunting.

The trace as follows witht he error in line 7 (up)
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/validations.rb:56:in `save!'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/attribute_methods/dirty.rb:33:in `save!'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/transactions.rb:246:in `save!'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/transactions.rb:295:in `with_transaction_returning_status'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/transactions.rb:208:in `transaction'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/transactions.rb:293:in `with_transaction_returning_status'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/transactions.rb:246:in `save!'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/validations.rb:41:in `create!'
> /usr/lib/ruby/gems/1.8/gems/fat_free_crm-0.11.1/db/migrate/20111201030535_add_field_groups_klass_name.rb:7:in `up'
> /usr/lib/ruby/gems/1.8/gems/fat_free_crm-0.11.1/db/migrate/20111201030535_add_field_groups_klass_name.rb:6:in `each'
> /usr/lib/ruby/gems/1.8/gems/fat_free_crm-0.11.1/db/migrate/20111201030535_add_field_groups_klass_name.rb:6:in `up'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:410:in `send'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:410:in `migrate'
> /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:410:in `migrate'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/connection_adapters/abstract/connection_pool.rb:119:in `with_connection'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:389:in `migrate'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:528:in `__send__'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:528:in `migrate'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:720:in `migrate'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:777:in `call'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:777:in `ddl_transaction'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:719:in `migrate'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:700:in `each'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:700:in `migrate'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:570:in `up'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/migration.rb:551:in `migrate'
> /usr/lib/ruby/gems/1.8/gems/activerecord-3.2.3/lib/active_record/railties/databases.rake:153
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `execute'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `invoke_with_call_chain'
> /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `run'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/bin/rake:33
> /usr/bin/rake:19:in `load'
> /usr/bin/rake:19
> Tasks: TOP => db:migrate
>

I have no clue, where the culprit lies. A stated above, the migrations runs happily when run at a unpacke ffcrm app.

So long,
Michael


On 24.04.2012, at 00:54, ben tillman wrote:

Reply all
Reply to author
Forward
0 new messages