好。俺也来补个
一个思路,没试过:tmp 目录下建个临时文件,往里面写临时代码,在 console 里面读该文件再 eval
每两个字节一个字符(中文汉字或者英文字母)
utf-16?
排后的还有 C++,C,java,php,lua。。。
直接加了个全局补丁。看起来是老版本对 mysql 的适配有问题
快十年前的版本了哦。。。
手动改改 migration 文件应该就行。不知道为啥 3.2 的版本生成的主键会 default null
盲猜 nginx 配错,请求没有转到 rails。看看 rails 日志有没有收到请求
你这学习教程有点老哦。多年前开始 rails 自带的 web 服务器就是 puma 了,不折腾
差别能有 0.4 秒
所以到底谁快谁慢?
贴个 benchmark 代码呗,也许其他人试着跑跑结果会不一样
从没见过真实项目中在 def 里嵌套 def。要达到同样的意图,在 def 里写 define_method 会更合适吧
这排版真是看得头大。参考排版
Projects.method(:require_dependencies)
就能打印 require_dependencies 方法定义在哪了
这是要发财呀。羡慕
确定服务器没开防火墙??
据我所知,不能把这个关系反过来。
是有这个问题,挂载时的内容会以宿主机为准,若挂载时宿主机的/data/public 是空的,那么/home/app/ntwebsite/public 也是空的。之后在容器中从新编译静态文件到 public 目录,就能在宿主机看到文件了
-v 把宿主机文件夹与容器的文件夹做个映射?
当初就是因为 vscode 没办法直接跳转到 gem 源码放弃了,还是转回了 rubymine。不知道为啥这么重要的功能 vscode 不支持。借楼问问 vscode 上各位是怎么处理这种需求的
如果 Ruby 继续保持过去十年来的衰落趋势,那各位一定要认真考虑学习这门语言的风险
我觉得原文这话说的有点。。。想象力?原作者不仅定义了“网红”,还定义了“风险”。
我在想原作者是不是收到个命题作文的要求,硬给凑了一篇。
确定是模仿这个 gem 再“写”一个 gem 包?而不是“用”这个 gem 包写个工具 ??
要真是前者,我很想知道你老师对工作难度的评估是怎样的。即使对工作几年的人来讲,重写一个偏底层 gem 也够喝一壶的了。对一个大二刚学 ruby 没多久的人,这个需求实在是强人所难
我刚刚试了一下,在 db 层做级联删除,rails 日志里面也会体现删除连结表记录的
你贴的删除日志应该不是因为 db 层的级联删除打印的,而是 rails 在模型层做的删除打印的。
我基本复制了 8 楼老哥的代码(rails 6.1),但修改了一些,创建中间表时直接使用 create_table, 且没有使用外键和级联删除的配置,如下:
def change
create_table :courses_teachers do |t|
t.belongs_to :course
t.belongs_to :teacher
t.timestamps
end
end
在 destroy person 对象后,依然能自动删除掉中间表。
2.7.2 :002 > Person.first.destroy
Person Load (0.4ms) SELECT "people".* FROM "people" ORDER BY "people"."id" ASC LIMIT ? [["LIMIT", 1]]
TRANSACTION (0.1ms) begin transaction
Teacher::HABTM_Courses Destroy (1.2ms) DELETE FROM "courses_teachers" WHERE "courses_teachers"."teacher_id" = ? [["teacher_id", 2]]
Teacher Destroy (0.2ms) DELETE FROM "people" WHERE "people"."id" = ? [["id", 2]]
TRANSACTION (1.8ms) commit transaction
=> #<Teacher id: 2, name: "spike", type: "Teacher", created_at: "2022-04-04 10:39:31.226942000 +0000", updated_at: "2022-04-04 10:39:31.226942000 +0000">
也许你需要一个更纯粹的代码例子来排查问题,你最初的代码里应该有其它的差异
直接加 on_delete: :cascade 的选项实际是在 DB 层做的级联删除,不是由 rails 在模型层做的删除,rails 日志应该不会体现 DB 层删除子记录。8 楼老哥的日志是能看到子记录和父记录放在同一个事务中的删除,所以你俩的代码其实不一样。(不排除版本差异问题)
不过确实能实现效果,而且这种形式是 gitlab 更倡导的级联删除方式。
通过对这些 Gem 的功能片段的阅读,可以让源码新手能从易到难,循序渐进的去培养阅读源码的能力。
这是个很理想的想法。多年前的我也有些这样的想法,想着先读完一个难度为 1 的源码,再去读难度为 2 的源码,逐渐继续,那么就能读下来难度为 100 的源码。但现实是复杂的,源码并不会标注自己是难度 1 还是难度 2,"难易"的评判是一个小马过河式的问题。
我跟 5 楼和 7 的看法一样,真要读 gem 源码时,一般是在使用 gem 时产生了些疑惑,或者需要魔改 gem。把“阅读源码”本身当作阅读源码的目的,我自己的结果是,容易失去重心,最终只学到些没见过的语法糖和 API。
如果楼主非要读 gem 源码,在掌握调试技能和熟悉 gem 公开 api 前提下,拉取 gem 的最初版本代码,配合他的单元测试,顺着测试单步调试,再难的 gem 都能看下来。当然,如果 gem 的单测写得不好,很可能说明没啥阅读价值。。。。
老哥你们要是把大小周去掉,估计人就会多些。看起来是每两周只多上一天的班,但一年算下来得多上一个月的班。这得多少个年假才抵得过来啊
有过。个把月都没有人说话
顺便提一句,在定义类时,rails 不提倡使用“限定常量”的形式,而是使用“相对常量”的形式,否则对于 classic 的 autoloader,有时会产生诡异的类加载错误。因此 class Api::V1::Com::OptionsController
最好能写成
module Api::V1::Com
class OptionsContoller < Api::V1::Com::BaseController
end
end
对于 Zeitwerk 的 autoloader,这两种写法没有区别
那就需要更多的信息了,坑可能在其他地方。rails 的常量自动加载机制已经变过几次了。随手试了下,这点代码信息在 rails 6 上没有复现问题。
错误信息就是答案
Unable to autoload constant Api::V1::Com::OptionsController, expected /mnt/workspaces/rails_projects/reviewservice/app/controllers/api/v1/com/options_controller.rb to define it
翻译:不能自动加载常量 Api::V1::Com::OptionsController,期望在 /mnt/workspaces/rails_projects/reviewservice/app/controllers/api/v1/com/options_controller.rb 中去定义这个常量。
类名与文件层次不对应
rails_param 这个 gem 倒是内置了你要的效果,在 action 中使用param! :tag_ids, Array
就能把逗号分隔的参数转为数组。不过单纯为了这个功能而引入一个 gem 有点划不来,可以考虑自己手动封装个类似的方法。
写成这样也 ok。但为什么不直接传数组勒
no wonder some parts are so slow...