direct_upload: true
的功能很方便,全交给客户端直接往云服务器上传,避免经过服务器,只需要这么一行:
<%= form.file_field :avatar, direct_upload: true %>
require 'open3'
cmd = 'ping www.google.com'
Open3.popen3(cmd) do |stdin, stdout, stderr, wait_thr|
while line = stdout.gets
puts line
end
end
https://medium.com/zendesk-engineering/running-a-child-process-in-ruby-properly-febd0a2b6ec8
对,这样有好处,可以自由增加各种各样的附件类型,无需调整数据库。
class Post < ApplicationRecord
has_one_attached :image
has_one_attached :cover
has_many_attached :images
has_many_attached :attachments
end
编写 aliyun-oss 存储实现的时候,顺便尝试了一把 ActiveStorage
与 Rails 结合很紧密,使用起来非常快捷简单,比 CarrierWave 好使很多!
增加了两个表:
active_storage_attachments
- 与业务表的多对多关系active_storage_blobs
- 附件的 Meta 信息,例如文件名,尺寸 ...假如我有个 photos
需要存储图片,大概是这样:
class Photo < ApplicationRecord
has_one_attached :image
end
这里,photos
表将不需要 image
字段,而是依靠 has_one
的关系来关联 active_storage_attachments
表。
这样带来了新的问题,每次列表查询,如果需要头像,需要关联查询。
于是问题来了,这样多余的开销怎么办?
可以依靠 Cache 来解决
class Photo < ApplicationRecord
has_one_attached :image
def image_url
# cache_key 带了 @photo 的 updated_at 信息,所以,每次 Photo 更新的时候,缓存能自动失效
Rails.cache.fetch(self.cache_key("image_url")) do
self.image.service_url
end
end
end
文档很少,总共就 6 节,跟《Getting Real》似的,难道是因为就只有 Element 绑定的功能?
然后又自己搞着搞着搞出了 Rails 那些东西
那个 ./fib
文件有多大?
把当时你看到那个慢的 SQL 的执行日志(SQL 语句和执行时间)放出来看看
然后你拿那个 SQL 到你线上的 MySQL 里面去 EXPLAIN
看看
你开发环境不出问题,有可能是开发环境数据太少了
贴 config/application.rb 和 config/environments/production.rb 的配置
哦 我看错了,那个不是 Rails Session 的查询
你先把 Session 改为 Cookie 模式,避免用户首次请求就要卡数据库那里,然后再看看会不会卡住
其实反而是有些话,作为社区官方这边不好说,另一方面,这种事情不能单纯用对和错来贴标签,商业本来就是这么一回事情。
况且之前已经有不少过不少对这事儿的讨论了,都是成年人,该说的也有人说过了,能不能去,值不值每个人应该有自我的判断力。
社区只能说保持开放的态度保留不同的看法。
难道非得要什么事情,都要表个态么?
应该是低于 16,并发的时候,1s 的响应速度可能会变成 1.5s
控制台 -> 设置
-> custom_head_html
手写 HTML 代码,例如:
<link rel="icon" href="//l.ruby-china.com/photo/2016/c309db0b49cab85a32f756541ea0e2b0.png" />
<style type="text/css">
// 自定义 CSS
</style>
贴配置
你给个正确的 Email 不就可以了么,username 也是,为何给一个字母 + 数字格式的?
顺带还有一个细节:
number of seconds that a connection will be kept unused in the pool before it is automatically disconnected (default 300 seconds)
大概意思是连接实际上有个超时时间(默认 300s)超时以后会自动释放
如果上面 find_each
的 block 异常了,理论上你们这个代码还存在 Connection 泄漏的问题
def update_entries
# 查询数据库中的记录
Entry.find_each do |e|
# 1. 调用第三方api, 查询记录信息
# 2. 处理信息
# 3. 保存
end
ensure
ActiveRecord::Base.clear_active_connections!
end
这个 update_entries
函数可能是一些非 Web 的地方调用的,例如 Rake 命令的批量处理动作。
Rails 是会自动处理数据库连接释放的事情,但 ActiveRecord 不会。
在非 Web 的场景,是需要手动调用 ActiveRecord::Base.clear_active_connections!
的
没上下文,无法回答
还是要看代码具体是干啥了
GitLab 和 GitHub 真挺好使的,你不用搞了,Bug 管理要结合代码仓库用的,这样采用关联,Review 流程,CI 等等等等。
docker-compose.yml
自行学习
Nginx 的 root
没有正确设置到 Rails 项目的 public 路径
server {
root /path/to/your/rails/app/public;
location / {
...
}
}