Forum: Rails-ES rake migrate con sqlserver

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Angel Mauricio Pino Gonzalez (Guest)
on 2007-01-18 18:54
(Received via mailing list)
estoy haciendo lo siguiente :

class O2k70001 < ActiveRecord::Migration
  def self.up
    # Crear tabla Usuarios
  create_table :usuarios do  |t|
    t.column :nombre_corto, :string, :limit => 30, :null => false
  end
  # Poblar un usuario
  Usuario.create :nombre_corto => "ampino"

  end

  def self.down
    # Eliminar tabla
    drop_table :usuarios
  end
end


mi database.yml dice :

development:
  adapter: sqlserver
  database: O2K7_development
  username: sa
  password: xxx
  host: 128.1.128.1

test:
  adapter: sqlserver
  database: O2K7_test
  username: sa
  password: xxx
  host: 128.1.128.1

production:
  adapter: sqlserver
  database: O2K7_production
  username: sa
  password: xxx
  host: 128.1.128.1


al hacer el
rake migrate -t

crea bien la tabla, pero al cargarla me sale:

C:\Wrk\www\O2K7>rake migrate --trace
(in C:/Wrk/www/O2K7)
** Invoke migrate (first_time)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
== O2k70001: migrating
========================================================
-- create_table(:usuarios)
   -> 0.0000s
rake aborted!
uninitialized constant Usuario
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:123:in
`const_missing'
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependenci
es.rb:131:in `const_missing'
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependenci
es.rb:133:in `send'
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependenci
es.rb:133:in `const_missing'
./db/migrate//001_o2k70001.rb:18:in `real_up'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:210:in `send'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:210:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:210:in `measure'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:210:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:332:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:327:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:327:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:294:in `up'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/migration.r
b:285:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.4/lib/tasks/databases.rake:4
c:/ruby/lib/ruby/gems/1.8/gems/rails-1.1.4/lib/tasks/databases.rake:3:in
`call'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:357:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in
`synchronize'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:364:in
`invoke_prerequisit
es'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `send'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:999:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:363:in
`invoke_prerequisit
es'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:356:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in
`synchronize'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7
c:/ruby/bin/rake:18:in `load'
c:/ruby/bin/rake:18


vi algo similar usando MYSQL y dice que instale la gema
correspondiente, pero eso no funciona con sqlserver.

gracias

--
Angel Mauricio Pino G
removed_email_address@domain.invalid
Movil: 08-577.92.72
javier ramirez (Guest)
on 2007-01-18 19:10
(Received via mailing list)
>    -> 0.0000s
> rake aborted!
> uninitialized constant Usuario
>
Eso te pasa porque con las migrations cuando creas una tabla rails no se
entera de que esa tabla ya existe ni crea el modelo en ese ciclo. La
solución inmediata es justo antes de trabajar con un modelo recién
creado/modificado hacerle un

Dispatcher.reset_application!

para forzarle a que te recargue la estructura de los modelos

De todos modos, lo de meterle datos en las migrations directamente te
acabará dando problemas en proyectos un poquito
grandes porque modidicas el modelo más tarde y le metes callbacks o
validaciones y alguien empieza de cero con tu migration
y como esos campos no los tiene le da errores.

La opción recomendada es sacar la carga de datos a una tarea rake y no a
las migrations.

suerte

javier ramírez
Xavier N. (Guest)
on 2007-01-21 01:58
(Received via mailing list)
On Jan 18, 2007, at 5:54 PM, Angel Mauricio Pino Gonzalez wrote:

>
>
>   username: sa
>
> ** Execute environment
> ** Execute db:migrate
> == O2k70001: migrating
> ========================================================
> -- create_table(:usuarios)
>    -> 0.0000s
> rake aborted!
> uninitialized constant Usuario

La creacion de la tabla no implica la definicion de la clase. Existe
usuario.rb en app/models?

-- fxn
javier ramirez (Guest)
on 2007-01-21 12:43
(Received via mailing list)
> La creacion de la tabla no implica la definicion de la clase. Existe
> usuario.rb en app/models?
>
cierto... en mi mismo mail de esta cadena hacía un comentario sobre
reiniciar el dispatcher cuando creas/modificas un modelo y lo dije MAL.
Cuando creas por primera vez la tabla, si ya tienes tu modelo todo
debería ir OK, porque la definición de los campos coincide. Si no lo
tienes, como bien dice Xavier, no va a ser capaz de encontrarlo.

lo que yo comentaba es válido solamente para las modificaciones... si
cambias una columna en una migration (sobre un model que ya tenías) e
intentas usar el modelo para meterle datos, como no coinciden los datos
del modelo y de la tabla, te da el mismo error. En este caso la
solución sí es hacer el reset que te comentaba para trabajar con la última
versión de la clase y no la que tenía ya cargada.
Xavier N. (Guest)
on 2007-01-21 13:07
(Received via mailing list)
On Jan 21, 2007, at 11:42 AM, javier ramirez wrote:

>
> lo que yo comentaba es válido solamente para las modificaciones... si
> cambias una columna en una migration (sobre un model que ya tenías) e
> intentas usar el modelo para meterle datos, como no coinciden los
> datos
> del modelo y de la tabla, te da el mismo error. En este caso la
> solución
> sí es hacer el reset que te comentaba para trabajar con la última
> versión de la clase y no la que tenía ya cargada.

Enefectiviwonder compadre :-), y ademas de hacerlo asi tambien se
puede invocar un metodillo expresamente pensado para eso:

   Usuario.reset_column_information

Para los que no siguieron el thread la situacion en la que eso se usa
es una secuencia de migrations tal que asi:

   1. defino tabla Xs
   2. uso clase X en una migration (dispara su carga)
   3. añado columna C a tabla Xs
   4. uso C en la clase X en una migration

Si no se nada 4 peta porque la metadata de la clase X se cargo en 2,
donde C no estaba definida.

-- fxn

P.D.: Esa no era la situacion en el mail original, es solo que le
hemos dado una vuelta mas al tema.
This topic is locked and can not be replied to.