https://stackoverflow.com/questions/30302021/rails-runner-without-spring
This happens because you are using the spring gem and your bin folder has been "springified".
If you take a look in the bin/rails file you will see that spring is loaded before moving on with running whatever you requested from it.
@jasl 周边有没有实物照片呀,模特照片看着效果不是很好。
而且如果你们用了 auto-scale 的话,要看一下减少机器的时候,是怎么通知进程关闭的。
如果是暴力的关闭进程,那有可能造成数据状态不对。假设 limit 确实是基于 redis 记录当前有多少几个任务同时再跑,那么如果暴力关闭的话,就会造成 redis 数据状态和实际状态对不上,也就可能 block queue 了
一个 sidekiq queue 动不了了
是指设置了 limit 的 queue 动不了了?
这种问题的话,大家都没有你的环境可以重现,所以只能给你个思路自己 debug:
报名
@flystax 能给新人个机会么
@uestc_bird 其实我觉得你可能是误解我的意思了。我觉得这里其实并不是能用主义。我想表达的意思是。当我们要解决一个问题时,如果身边没有一个完完全全刚刚合适的解决方法时,如果身边有一些方法能解决这个问题,但是用起来又不是那么直接的时候,这种情况下,我们或许能考虑稍微将其改造一下使用。
比如说,我本身需要一个梯子去拿高处的东西,但是身边刚好没有梯子,但是有几个凳子,我就可以去拿这个凳子来帮助我去解决增加我高度的问题。
这个思维的核心其实在于一个权衡,在完全从头搞出一个解决这个问题所需要的消耗与改造这些并不完全合适的方法所需要消耗之间做出权衡。当然还要考虑改造后的这个方法本身是否会出现各种问题。
还是刚刚梯子的例子,我如果要重新做一个梯子的话,我要去买木材,做测量,做切割等等,如果我不太会木工,可能还得学学怎么加工木头。而用凳子去做一个梯子的话,可能很快就能搭建起一个高台,但是单纯用凳子搭建出来的高台可能并不稳定,特别如果是搭建的高度还比较高的话,我或许要需要做一些其他工作来保证高台的安全性。所以到底怎么选,我就要考虑本身的需求(增加我能够到的高度),目前可用方法的特性(凳子的特性),另辟蹊径的代价(重新造梯子)等等。
@leiz_me 嗯,明白了。我去学习一下:)
我知道,但是从错误提示来看,一开始就可以定义到 order,然后就可以跟踪到调用主体出问题了。你觉得你要继续探究,就去看你 User 执行 _where 和 micropost 执行 _where 具体执行过程中关键输出是什么。我觉得他们执行的逻辑在里面是不一样的,不过这是直观感觉,没有仔细分析代码,你可以试着去看看
@catherine 共同学习,我也突然才反应过来,那个 sql 语句提示的是 'order' 这个方法没有成功,应该一早就从 order 这里去开始调试的。可以节省很多时间的。还是不够敏感。
@catherine 既然有方向了,你就慢慢去调试吧,我对你的场景也不了解。你更了解你的代码在做什么。我只是帮你找个方向而已,剩下的就自己努力吧。
@catherine 能否把实验过程的信息发出来。把 model 的输出结果和 default 里面的输出信息都发出来看一下
@catherine 你在 default 方法里面输出 self。看执行他的是什么。因为出错信息里面已经明确看出来是没有给出表格的名字,所以你先看你执行查询方法的主体是什么。
而且你能解释一下
def default(params, options = {})
._where(params[:where])
.order(params[:order]||"created_at desc")
end
这个方法里面,你直接通过.method
来调用方法,这个执行主体是哪一个呢?我看的代码不多,没有见过这样的用法,能否讲解一下?
注意你第一次出错的时候提示输出的 SQL 语句
SELECT "".* FROM "" ORDER BY "microposts"."created_at" DESC, created_at desc
from 后面跟的是空字符,也就是没有指定 table。
所以我猜测是你 model 方法的问题。
@pathbox thx @watraludru 了解了
我觉得挺好的,新人一开始就知道这些概念对刚开始学习还是有比较大的作用的。虽然这些对于老鸟来说是基本到不能在基本的东西了。但是对于刚入这个领域的人来说,首先知道常用东西的概念是很有必要的。虽然在学习过程中这些都会慢慢接触到。但是一开始有一个大概的印象我觉得对学习过程来说还是能有不少帮助的。至少能减少些挫折感(比如觉得有很多概念)。
举个最简单的例子,比如大家炒股,对于新入股市的人来说,“套牢”、“大盘”、“蓝筹股”这些概念肯定不熟悉,但是这些又是很多股市分析中常用到的名词,如果你在学习炒股前期就大概知道这些名词的意思,我相信你在学习炒股和看相关分析的时候,肯定更为容易一些。
所以对于这些基本概念的汇集我觉得并不是完全没有什么用的。所以我觉得大家对“有用”标准不要那么太高了,毕竟面向的对象不同。 @kirahu @easonlovewan @pengedy 你们说是么?
而且我觉得,如果大家觉得这个并不是真正重要的,那或许应该告诉他哪些才是更重要的,至少也给别人一个方向,这样至少比回复“这个并没有什么用”有用多了。
@qinfanpeng :plus1:
@msg7086 了解了
@emayej @hanluner @nowherekai @qinfanpeng 我去研究一下相关源码,看看到底是怎么回事。谢谢大家了
你这个我做了实验,只要添加了 belongs_to,就会存在相应的方法。 而且从输出的 sql 来看,可以猜测 belongs_to 添加的方法就是去寻找相应的 column 中的值,并将该值作为去相关 table 中查找的目标。例如我的 Model 中存在正常的 Article 和 Comment 的关系,当我用 comment 去输出 article 时。
comment.article
其输出的 sql 是:
SELECT "articles".* FROM "articles" WHERE "articles"."id" = ? LIMIT 1 [["id", 1]]
而当不存在 Nowhere table 的时候,直接返回的是 nil,没有输出 sql 语句。所以我猜想 belongs_to 产生的方法,在具体实现的时候会去检查数据库里面是否有相应的 table。
@qinfanpeng 通过你这种方法,我发现很奇怪的地方。无论是否设置 foreign_key,产生的 sql 是一样的。并没有设置 foreign_key 的 sql 语句。而且我用的数据库是 sqlite,也支持 foreign_key
建立两个 model,Article 与 Comment
class CreateArticles < ActiveRecord::Migration
def change
create_table :articles do |t|
t.string :title
t.text :text
t.timestamps null: false
end
end
end
class CreateComments < ActiveRecord::Migration
def change
create_table :comments do |t|
t.string :commenter
t.text :body
t.references :article, index: true # ,foreign_key: true
t.timestamps null: false
end
end
end
不设置 foreign_key
CREATE TABLE "schema_migrations" ("version" varchar NOT NULL);
CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version");
CREATE TABLE "articles" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar, "text" text, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL);
CREATE TABLE "comments" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "commenter" varchar, "body" text, "article_id" integer, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL);
CREATE INDEX "index_comments_on_article_id" ON "comments" ("article_id");
INSERT INTO schema_migrations (version) VALUES ('20160105114731');
INSERT INTO schema_migrations (version) VALUES ('20160105120123');
设置 foreign_key 为 true
CREATE TABLE "schema_migrations" ("version" varchar NOT NULL);
CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version");
CREATE TABLE "articles" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "title" varchar, "text" text, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL);
CREATE TABLE "comments" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "commenter" varchar, "body" text, "article_id" integer, "created_at" datetime NOT NULL, "updated_at" datetime NOT NULL);
CREATE INDEX "index_comments_on_article_id" ON "comments" ("article_id");
INSERT INTO schema_migrations (version) VALUES ('20160105114731');
INSERT INTO schema_migrations (version) VALUES ('20160105121912');
@hanluner 那我是不是可以这么理解了。
@hanluner database 中的 foreign keys 就是通过 add_foreign_key 这些在 database 中添加的 foreign key。我这里的提的问题我换一个叙述可能容易理解一点。 我们只考虑数据库建模的话。如果我们要表示 order 属于 customer 的关系话。一般的实现方式就是在 order 的 table 中去建立一个 customer_id 的 column,并且通过 sql 语句明确指出这是一个 foreign key。 但是这里 rails model 去实现这个关系的时候,在数据库中的操作只是建立了一个 customer_id 的 column,并为这个 column 建立了一个 index。并没有在数据库层面上明确出这是一个 foreign key(也就是没有通过 sql 语句去说明这个 column 是 foreign key)。
所以我就有了上面 3 个问题
@joiny_cam 感觉直接把电话发出来不太好吧。不在乎自己的隐私?
等我再锻炼一段时间内力,我一定会去应聘!