[英]ActiveRecord Postgres adapter generating invalid SQL WHERE clause: WHERE(“fieldname”)
ActiveRecord 4.1.1 is generating some peculiar SQL on save that postgres is choking on: ActiveRecord 4.1.1在保存时生成了一些奇怪的SQL,而这些都是postgres遇到的:
SELECT "projects".* FROM "projects" WHERE ('uid') LIMIT 1
PG::InvalidTextRepresentation: ERROR: invalid input syntax for type boolean: "uid"
I'm pretty sure that the "boolean" being referred to here is actually the WHERE()
syntax which is expecting a boolean expression as an argument. 我很确定这里引用的“布尔值”实际上是WHERE()
语法,它期望布尔表达式作为参数。
uid
is defined as the primary key on my model (see below)... but why is it just saying WHERE('uid')
when it's doing select_all (see stacktrace)? uid
被定义为模型的主键(请参见下文)...但是为什么在执行select_all时仅说WHERE('uid')
(请参见stacktrace)? (and why is it doing select_all on save?) (为什么它在保存时执行select_all?)
p = Project.new(name: "test", description: "test", workflow_id: 1)
=> #<Project name: "test", description: "test", user_id: nil, uid: nil, created_at: nil, updated_at: nil, workflow_id: 1, active: nil>
irb(main):031:0> p.save
(1.9ms) BEGIN
Project Load (5.5ms) SELECT "projects".* FROM "projects" WHERE ('uid') LIMIT 1
PG::InvalidTextRepresentation: ERROR: invalid input syntax for type boolean: "uid"
LINE 1: SELECT "projects".* FROM "projects" WHERE ('uid') LIMIT 1
^
: SELECT "projects".* FROM "projects" WHERE ('uid') LIMIT 1
(1.7ms) ROLLBACK
ActiveRecord::StatementInvalid: PG::InvalidTextRepresentation: ERROR: invalid input syntax for type boolean: "uid"
LINE 1: SELECT "projects".* FROM "projects" WHERE ('uid') LIMIT 1
^
: SELECT "projects".* FROM "projects" WHERE ('uid') LIMIT 1
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/postgresql_adapter.rb:815:in `async_exec'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/postgresql_adapter.rb:815:in `block in exec_no_cache'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract_adapter.rb:373:in `block in log'
from /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.1/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract_adapter.rb:367:in `log'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/postgresql_adapter.rb:815:in `exec_no_cache'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:137:in `exec_query'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/postgresql_adapter.rb:947:in `select'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract/database_statements.rb:31:in `select_all'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract/query_cache.rb:69:in `select_all'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/querying.rb:39:in `find_by_sql'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/relation.rb:603:in `exec_queries'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/relation.rb:487:in `load'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/relation.rb:231:in `to_a'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/relation/finder_methods.rb:451:in `find_take'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/relation/finder_methods.rb:98:in `take'
... 41 levels...
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract/database_statements.rb:211:in `block in transaction'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract/database_statements.rb:219:in `within_new_transaction'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract/database_statements.rb:211:in `transaction'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/transactions.rb:208:in `transaction'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/transactions.rb:326:in `with_transaction_returning_status'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/transactions.rb:268:in `block in save'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/transactions.rb:283:in `rollback_active_record_state!'
from /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/transactions.rb:267:in `save'
from (irb):31
from /app/vendor/bundle/ruby/2.0.0/gems/railties-4.1.1/lib/rails/commands/console.rb:90:in `start'
from /app/vendor/bundle/ruby/2.0.0/gems/railties-4.1.1/lib/rails/commands/console.rb:9:in `start'
from /app/vendor/bundle/ruby/2.0.0/gems/railties-4.1.1/lib/rails/commands/commands_tasks.rb:69:in `console'
from /app/vendor/bundle/ruby/2.0.0/gems/railties-4.1.1/lib/rails/commands/commands_tasks.rb:40:in `run_command!'
from /app/vendor/bundle/ruby/2.0.0/gems/railties-4.1.1/lib/rails/commands.rb:17:in `<top (required)>'
from /app/bin/rails:4:in `require'
from /app/bin/rails:4:in `<main>
class Project < ActiveRecord::Base
self.primary_key = "uid"
end
module ActiveRecordUIDExtension
extend ActiveSupport::Concern
def generate_uid
return unless self.class.column_names.include?("uid")
self.id = SecureRandom.random_number(36**10).to_s(36)
while !self.class.find_by(:uid, self.id).nil? do
self.id = SecureRandom.random_number(36**10).to_s(36)
end
end
end
ActiveRecord::Base.send(:include, ActiveRecordUIDExtension)
ActiveRecord::Base.send(:before_create, :generate_uid)
activerecord (4.1.1)
activemodel (= 4.1.1)
activesupport (= 4.1.1)
arel (~> 5.0.0)
Your mixin doesn't make any sense. 您的mixin没有任何意义。 This part right here is causing the bad SQL: 这部分正在导致错误的SQL:
self.class.find_by(:uid, self.id)
That's producing invalid SQL because you're telling it to. 产生无效的SQL是因为您要告诉它。 find_by
has a flexible interface so it has to do some parsing to see how you're calling it. find_by
具有灵活的接口,因此必须进行一些解析才能查看您如何调用它。 When you say: 当你说:
find_by(a, b)
the argument parsing probably assumes that you're trying to use this form: 参数解析可能假设您正在尝试使用以下形式:
find_by('some_sql_snippet', placeholder_valid)
as in this example from the docs: 如本例中的文档所示:
find_by("published_at < ?", 2.weeks.ago)
Then it will probably to_s
the first argument and scan it for placeholders. 然后,它可能会to_s
的第一个参数和扫描其中的占位符。 When you say: 当你说:
find_by(:uid, self.id)
you'll end up with :uid.to_s
and self.id
will be ignored because there aren't placeholders in that string. 您将最终得到:uid.to_s
并且self.id
将被忽略,因为该字符串中没有占位符。 That would explain why you're seeing where ('uid')
in the SQL. 这就可以解释为什么您会在SQL中看到where ('uid')
。
Fix your mixin to make sense: 修复mixin使其有意义:
self.class.find_by(:uid => self.id)
or better, switch to exists?
还是更好,切换到exists?
to avoid building a whole model instance just to see if there's a row in the database: 为了避免仅查看数据库中是否存在一行而构建整个模型实例:
self.class.where(:uid => self.id).exists?
self.class.exists?(:uid => self.id)
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.