放在一个队列,然后只给一个线程执行这个队列?
很好,我选择 steam
Wish!
我感觉这种方式几乎是直接把后端的模型暴露给了前端
它实际是多抽象了一层(GraphQL 里叫 type,JSONAPI 里应该叫 resource)。由于可以使用框架命令根据 DB schema 来生成这一层的内容,所以看起来像是暴露了模型。然而实际在项目里必然会更改这些生成的代码,删除大量的 meta data 字段,重新定义字段
跟传统 API 的区别在于,传统 API 返回的某些字段可能是后端计算之后返回的,也就是说返回的 JSON 结构跟后端模型结构并不是完全一致的
拿 GraphQL 举例,type 中的字段逻辑是可以自定义的,当前端想要 full_name, 而数据库只有 first_name 和 last_name,完全可以在对应的 type 中定义一个 full_name 字段。前端想要日期格式的 created_at, 而 DB 只有 time 格式的 created_at, 也可以在对应的 type 中转换。甚至你也可以完全定义一个不对应任何模型的 type 出来。所以只要后端肯干,完全可以不把业务逻辑交给前端。
Graphql 就把当前问题搞大了点,相信楼主没有时间去改造框架,也很难短时间说服前端去用 Graphql。
感觉这个问题主要看前后端谁是主导地位,前端主导的话,估计就要单写个聚合接口了(面向 UI 设计接口)。后端主导的话,如果其他几个接口没有互相依赖的话,可以酌情复用接口。前后端谁也说服不了谁的时候,于是就出现了数据中台。。。但是一般小公司也不会有中台
不需要这么复杂,直接用宿主机的 ip 地址即可,在 zshrc 中加一段脚本设置代理地址
host_ip=`tail -1 /etc/resolv.conf | cut -d' ' -f 2`
export ALL_PROXY=$host_ip:7890
好。俺也来补个
一个思路,没试过: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 的单测写得不好,很可能说明没啥阅读价值。。。。
老哥你们要是把大小周去掉,估计人就会多些。看起来是每两周只多上一天的班,但一年算下来得多上一个月的班。这得多少个年假才抵得过来啊
有过。个把月都没有人说话