Data too long for column 'crypted_password' with DM admin install

[auxbuss]

Generte a padrino project. Generate admin. Migration with DataMapper works okay to MySQL, seed fails, as follows:

$ padrino-gen project myproject -t shoulda -e haml -c sass -s jquery -d datamapper -a mysql
$ cd myproject
$ padrino-gen admin
$ padrino rake dm:migrate
=> Executing Rake dm:migrate ...
DataObjects::URI.new with arguments is deprecated, use a Hash of URI components (/usr/lib/ruby/gems/1.8/gems/dm-do-
adapter-1.1.0/lib/dm-do-adapter/adapter.rb:231:in `new')
 == Performing Up Migration #1: create_accounts
   CREATE TABLE `accounts` (`id` SERIAL PRIMARY KEY, `name` VARCHAR(50), `surname` VARCHAR(50), `email` 
   VARCHAR(50), `crypted_password` VARCHAR(50), `role` VARCHAR(50)) ENGINE = InnoDB CHARACTER SET utf8 
   COLLATE utf8_general_ci
   -> 0.0370s
 -> 0.0408s
<= dm:migrate:up  executed
$ padrino rake seed
=> Executing Rake seed ...
DataObjects::URI.new with arguments is deprecated, use a Hash of URI components (/usr/lib/ruby/gems/1.8/gems/dm-do-
adapter-1.1.0/lib/dm-do-adapter/adapter.rb:231:in `new')
Which email do you want use for logging into admin? admin@tester.com
Tell me the password to use: tester

rake aborted!
Data too long for column 'crypted_password' at row 1

Tasks: TOP => seed
(See full trace by running task with --trace)
$

Last few lines of stack trace:

/usr/lib/ruby/gems/1.8/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:114:in execute_non_query' /usr/lib/ruby/gems/1.8/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:114:increate'
/usr/lib/ruby/gems/1.8/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:276:in with_connection' /usr/lib/ruby/gems/1.8/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:113:increate'
/usr/lib/ruby/gems/1.8/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:85:in each' /usr/lib/ruby/gems/1.8/gems/dm-do-adapter-1.1.0/lib/dm-do-adapter/adapter.rb:85:increate'
/usr/lib/ruby/gems/1.8/gems/dm-core-1.1.0/lib/dm-core/repository.rb:146:in create' /usr/lib/ruby/gems/1.8/gems/dm-core-1.1.0/lib/dm-core/resource/state/transient.rb:61:increate_resource'
/usr/lib/ruby/gems/1.8/gems/dm-core-1.1.0/lib/dm-core/resource/state/transient.rb:25:in commit' /usr/lib/ruby/gems/1.8/gems/dm-core-1.1.0/lib/dm-core/resource.rb:957:in_persist'


Cheers,
Marc

[nesquena]

What does your gemfile look like? It's almost as if you are trying to load AR 2.3.8 from the Gemfile directly.

[auxbuss]

Sorry, please ignore the separate AR issue. It's not the main issue. Sorry. My fault. The DataMapper issue is real, though.

[nesquena]

@DAddYE I feel like we run into this problem a lot for some reason....why is crypted password only 50 length when I thought we set string default to 255?

[DAddYE]

Seems an issue of datamapper if you use DataMapper.auto_upgrade! handle correctly size, from migrations seems to ignore them.

[nesquena]

Really frustrating, can't we set the size explicitly in the migration to alleviate this. I see this reported alot.

[DAddYE]

Yep @dkubb any workaround for this big big problem with DM migrations?

[dkubb]

The DataMapper.auto_upgrade! method only makes additive changes to the schema, that is it adds new tables, indexes and columns but does not modify anything preexisting. Mostly this was done for safety to avoid making schema changes that result in a loss of information. To have the schema reset to match the models DataMapper.auto_migrate! is what you use. For something in between where you want to modify an existing schema, you use the "classic migrations" API.

The limitations in DataMapper.auto_upgrate! may be removed in the future so some safe changes are performed automatically; like lengthening a CHAR column, or changing a column from NOT NULL to NULL allowed. This new feature won't be added for a while though since our time is limited and we're focused on refactoring the query system atm.

I'm not familiar with padrino's codebase, so if someone could point me towards where the migration is declared or the model is defined I can look into this.

[DAddYE]

@dkubb the problem is that we have set:

DataMapper.logger = logger
DataMapper::Property::String.length(255)

case Padrino.env
  when :development then DataMapper.setup(:default, !DB_DEVELOPMENT!)
  when :production  then DataMapper.setup(:default, !DB_PRODUCTION!)
  when :test        then DataMapper.setup(:default, !DB_TEST!)
end

When u use the auto_upgrade/auto_migrate it handle correctly the string lenght and create a column with varchar(255).

This didn't happen if you perform migration with db:migrate create columns with varchar(50)

Also setting in the migration :lenght => 255 or :size => 255 or any kind see in yours docs, the generated colum still have varchar(50)

Why?

[dkubb]

@auxbuss can you provide an example of the migration script you're trying to run? Or is it coming from something in padrino?

@DAddYE I'm looking into it. The code is supposed to take the options for the type, in this case DataMapper::Property::String and use them as defaults when other options aren't specified. The actual DDL generation uses the same code path as auto-migration, so there's probably a bug in the code that takes the migration script and generates the options for DDL generation.

I'll start off by looking at what the migration script passes in and work backwards to find out why the options provided to the DDL generator are invalid.

[auxbuss]

This is a clean install. I'm familiar with sinatra, I'm trying padrino for the first time. Hence my repeat steps in my first post.

$ padrino-gen project myproject -t shoulda -e haml -c sass -s jquery -d datamapper -a mysql
$ cd myproject
$ padrino-gen admin
$ padrino rake dm:migrate
$ padrino rake seed
...

[nesquena]

@dkubb Here's a gist with relevant files (generated model, migration, and database.rb which sets 255 default): https://gist.github.com/1015239

[DAddYE]

@dkubb any suggestion for us?

[dkubb]

@DAddYE I just built a new padrino project using the following steps and was able to see the problem. However I was also able to fix it by specifying :length => 255 explicitly in the migration (I just triple checked it, and can confirm this works).

# initial gem setup
rvm use @myproject_development --create
gem install rake bundler padrino addressable bcrypt-ruby data_mapper dm-mysql-adapter haml rack-flash rack-test sass shoulda

# setup test database
mysqladmin create myproject_development

# create project and install dependencies
padrino-gen project myproject -t shoulda -e haml -c sass -s jquery -d datamapper -a mysql
cd myproject
bundle

# fix broken test/test.rake generated by padrino
echo "require 'rake/dsl_definition'" | cat - test/test.rake | tee test/test.rake > /dev/null

padrino-gen admin
padrino rake dm:migrate
padrino rake seed

Also, I have a fix in edge dm-migrations that should resolve this problem and make it unnecessary to explicitly specify :length in the migrations. It be part of the next DM 1.1.1 release. However we don't have a release date for it yet because there are a few unrelated issues to work through.