es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

El parámetro de límite no parece funcionar en las migraciones de Rails 6.1.4.1.

12 Jul, 2023 Programación

Después de generar migraciones, siempre cambio el valor predeterminado t.timestamps, porque otras aplicaciones de la base de datos Postgres tienen problemas con la gran precisión que tienen estas marcas de tiempo predeterminadas. Además, me gusta que la base de datos establezca la marca de tiempo (en lugar de que Rails lo haga por mí), de ahí el 'CURRENT_TIMESTAMP'

class CreateUsers < ActiveRecord::Migration[6.1]
  def change
    create_table :users do |t|
      t.string :name

      t.timestamps limit: 3, default: -> { "timezone('utc', now())" }, null: false
    end
  end
end

Recientemente actualicé a Rails 6.1.4.1 (venía de Rails 5.2)

La configuración limit: 3 parece ya no funcionar. No muestra ninguna advertencia, pero al revisar la base de datos Postgres, el tipo de dato es timestamp y no timestamp(3) como suele ser después de ejecutar esas migraciones.

Tags:  ,

Answer

  1. Avatar for davy.ai
    davy.ai

    Como experto en TI especializado en postgresql y ruby-on-rails-6, me he encontrado con un problema con la configuración limit: 3 en las migraciones después de actualizar a Rails 6.1.4.1 desde Rails 5.2. Esta configuración se utiliza para limitar la precisión de t.timestamps, pero parece que ya no funciona. Al verificar la base de datos de Postgres, muestra que el tipo de dato es timestamp en lugar de timestamp(3) como se esperaba.

    Para resolver este problema, puedes modificar el archivo de migración para especificar el parámetro precision en lugar de limit. Por ejemplo:

    class CreateUsers < ActiveRecord::Migration[6.1]
  def change
    create_table :users do |t|
      t.string :name
      t.timestamps precision: 3, default: -> { "timezone('utc', now())" }, null: false
    end
  end
end

    Esto establece la precisión de t.timestamps en 3 y utiliza la función CURRENT_TIMESTAMP en Postgres para establecer el valor de fecha y hora en lugar de que Rails lo establezca. Esto debería garantizar que el tipo de dato en la base de datos de Postgres sea timestamp(3) como se esperaba.

Comments are closed.