New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
auxbuss opened this Issue Jun 7, 2011 · 13 comments

Comments

Projects
None yet
4 participants
@auxbuss

auxbuss commented Jun 7, 2011

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

This comment has been minimized.

Show comment
Hide comment
@nesquena

nesquena Jun 7, 2011

Member

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

Member

nesquena commented Jun 7, 2011

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

This comment has been minimized.

Show comment
Hide comment
@auxbuss

auxbuss Jun 7, 2011

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

auxbuss commented Jun 7, 2011

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

@nesquena

This comment has been minimized.

Show comment
Hide comment
@nesquena

nesquena Jun 7, 2011

Member

@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?

Member

nesquena commented Jun 7, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@DAddYE

DAddYE Jun 7, 2011

Member

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

Member

DAddYE commented Jun 7, 2011

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

@nesquena

This comment has been minimized.

Show comment
Hide comment
@nesquena

nesquena Jun 7, 2011

Member

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

Member

nesquena commented Jun 7, 2011

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

@DAddYE

This comment has been minimized.

Show comment
Hide comment
@DAddYE

DAddYE Jun 7, 2011

Member

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

Member

DAddYE commented Jun 7, 2011

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

@dkubb

This comment has been minimized.

Show comment
Hide comment
@dkubb

dkubb Jun 8, 2011

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.

dkubb commented Jun 8, 2011

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

This comment has been minimized.

Show comment
Hide comment
@DAddYE

DAddYE Jun 8, 2011

Member

@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?

Member

DAddYE commented Jun 8, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@dkubb

dkubb Jun 8, 2011

@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.

dkubb commented Jun 8, 2011

@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 comment has been minimized.

Show comment
Hide comment
@auxbuss

auxbuss Jun 8, 2011

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
...

auxbuss commented Jun 8, 2011

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

This comment has been minimized.

Show comment
Hide comment
@nesquena

nesquena Jun 8, 2011

Member

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

Member

nesquena commented Jun 8, 2011

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

@ghost ghost assigned DAddYE Jun 8, 2011

@DAddYE

This comment has been minimized.

Show comment
Hide comment
@DAddYE

DAddYE Jun 17, 2011

Member

@dkubb any suggestion for us?

Member

DAddYE commented Jun 17, 2011

@dkubb any suggestion for us?

@dkubb

This comment has been minimized.

Show comment
Hide comment
@dkubb

dkubb Jun 17, 2011

@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.

dkubb commented Jun 17, 2011

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment