¿Qué explica este extraño comportamiento? work_state es un atributo de estado derivado de aasm gem, pero no tengo problemas para consultar esto con otros modelos...
MaintenanceOrder.all.select { |m| m.work_state == "pending_work" }.size => 235 MaintenanceOrder.all.pluck(:work_state).select { |s| s == "pending_work" }.size => 235 MaintenanceOrder.last.work_state => "pending_work" # so at this point... obviously there are MaintenanceOrders with work_state of "pending_work", and yet... MaintenanceOrder.where(work_state:"pending_work").size => 0Según lo solicitado, este es el estado establecido
aasm(:work, column: "work_state",no_direct_assignment: true ) do state :pending_work, initial: true state :in_progress state :complete state :not_fixableLo que es más extraño es que las consultas funcionan con OTROS estados, es decir, esto funciona:
MaintenanceOrder.where(work_state:"in_progress").size => 12 También el SQL se ve bien cuando hago log_level = :debug
MaintenanceOrder.where(work_state:"pending_work").size (15.9ms) SELECT COUNT(*) FROM "maintenance_orders" WHERE "maintenance_orders"."work_state" = 'pending_work' => 0 Actualización sobre rarezas... ¿hay un problema gigante aquí que no conozco? Otro modelo tiene un problema SIMILAR. FWIW los estados con problemas, "pending_work" arriba y "pending_start" debajo, ambos son los estados iniciales predeterminados ...
Item.where(aasm_state: "pending_start").size => 19 # so at least some records are found, but not all of them Item.all.pluck(:aasm_state).select { |s| s == "pending_start" }.size => 19 Item.all.select { |i| i.aasm_state == "pending_start"}.size => 94 # If I delve a little deeper.... it appears that the where query is just picking up the last few records... even though there's no size limit indicated?? in other words where_ids = Item.where(aasm_state: "pending_start").map(&:id).sort select_ids = Item.all.select { |i| i.aasm_state == "pending_start"}.map { |i| i.id }.sort where_ids == select_ids.last(19) => trueOk, resolví esto ... pero de manera muy insatisfactoria porque es solo un misterio para mí. La solución fue diferente para los 2 casos diferentes anteriores. Parece que las causas fundamentales de los 2 fueron diferentes, pero también parece que en ninguno de los dos casos sabré la razón por la que...
Problema del modelo de orden de mantenimiento
Hice un montón de git diffs aquí para comprobar mi cordura. Literalmente... config.log_level = :debug en production.rb y luego empujé la aplicación a producción. Supervisé que se usaran las declaraciones SQL correctas en la consulta (como copié en la pregunta anterior). Luego restablecí config.log_level = :info y empujé a producción. Entonces, de repente, funcionó.
Ningún otro cambio... de repente, MaintenanceOrder.where(work_state:"pending_work").size devolvió el valor correcto
Problema con el modelo de artículo
Aquí, el hecho de que la consulta where estaba encontrando algunos pero no todos los registros, y que el subconjunto que estaba encontrando era solo reciente, me hizo preguntarme si tal vez los registros antiguos... se... guardaron... ¿incorrectamente de alguna manera? Después de todo, acababa de hacer una gran migración de base de datos.
Así que ejecuté Item.all.select {|i| i.aasm_state == "pending_start"}.each { |i| i.update_column(:aasm_state,"pending_start") } , y eso solucionó el problema