Rails 5 Active Record - возможно ли сохранить таблицу в памяти?

Question

Если у нас есть небольшая таблица, которая содержит относительно статические данные, можно ли активировать Active Record при запуске приложения и никогда не ударять по базе данных для этих данных?

Обратите внимание, что в идеале я хотел бы, чтобы эти данные были объединены в другие модели, имеющие отношения к нему.

Примером может служить список стран с их префиксным номером телефона - этот список вряд ли изменится, и если бы это было сделано, это было бы изменено администратором. Другие таблицы могут иметь отношения с этим (например, с учетом Пользователя, имеющего ссылку на страну, мы можем захотеть найти телефонный код страны).

Я видел аналогичный вопрос here, но ему 6 лет и относится к Rails 2, в то время как я использую Rails 5 и, возможно, с тех пор что-то было введено.

Предпочтительные растворы будут:

1. Встроенная функциональность Рельсы/ActiveRecord, чтобы загрузить таблицу один раз при запуске, и если другие записи впоследствии загружены, в которых есть отношения с кэш-таблице, то ссылку на кэшированную объектов (например, вручную кэшировать MyModel.all где-то недостаточно, так как отношения будут по-прежнему загружаться при запросе базы данных).
2. Поддерживается библиотека, которая делает выше.
3. Если ни один из них не доступен, я полагаю, что альтернативным методом было бы определить статический набор данных как enum/hash в памяти или аналогичный, и сохранить хэш-ключ в записях, которые имеют отношение к этим данным, и определить методы на эти модели для поиска с использованием объекта в хэше с использованием ключа, сохраненного в базе данных. Это кажется вполне руководство, хотя ...

[EDIT] Еще одна вещь, чтобы рассмотреть с потенциальными решениями - ручное решение (3) также потребует пользовательские контроллеры и маршруты для таких данных, чтобы быть доступными над API. В идеале было бы неплохо иметь решение, в котором такие данные могут быть предложены через API RESTful (только для чтения - только GET), если это необходимо, с использованием стандартных механизмов рельсов, таких как строительные леса, без чрезмерного вмешательства вручную.

Answer 1

Я думаю, что вы можете слишком быстро уклоняться от «простого»/«ручного» подхода.

Запись данных в хэш-массив рубинов не так уж плоха.

И если вы хотите использовать CRUD-эшафот, почему бы просто не использовать стандартную модель Rails/контроллер? Неужели так плохо хранить некоторые статические данные в базе данных?

Третий вариант заключается в том, чтобы хранить ваши данные в файле в каком-то сериализованном формате, а затем, когда ваше приложение загружает, прочитайте это и создайте объекты ActiveRecord. Позвольте мне привести пример:

данные.YML

--- 
- a: "1" 
    b: "1" 
- a: "2" 
    b: "2" 

Это YAML файл, содержащий массив хэшей; Вы можете построить такой файл с:

require 'yaml' 
File.open("path.yml", "w") do |f| 
    data = [ 
    { "a" => "1", "b" => 1 }, 
    { "a" => "2", "b" => 2 } 
    ] 
    f.write(YAML.dump(data)) 
end 

Затем, чтобы загрузить данные, вы можете создать файл в config/initializers/ (здесь все будет Автозагружаемого по рельсам):

конфигурации/инициализаторы/static_data.rb

require 'yaml' 

# define a constant that can be used by the rest of the app 
StaticData = YAML.load(File.read("data.yml")).map do |object| 
    MyObjectClass.new(object) 
end 

чтобы избежать необходимости писать миграции базы данных для MyObjectClass (если это на самом деле не хранятся в БД), вы можете использовать attr_accessor определения для вашего Атрибуты:

class MyObjectClass < ActiveRecord::Base 
    # say these are your two columns 
    attr_accessor :a, :b 
end 

просто убедитесь, что не запускать такие вещи, как save, delete или update на этой модели (если вы не monkeypatch этих методов).

Если вы хотите иметь конечные точки REST/CRUD, вам нужно будет написать их с нуля, потому что теперь можно изменить данные. Вам в основном нужно делать какие-либо обновления в 3 этапа:

1. нагрузку данные из YAML в список объектов Ruby,
2. изменить список рубин объект
3. сериализовать все, чтобы YAML и сохранить его ,

Итак, вы можете видеть, что здесь вы не делаете инкрементных обновлений. Вы можете использовать JSON вместо YAML, и у вас будет такая же проблема. С построенной в Ruby системой хранения PStore вы сможете обновлять объекты на индивидуальной основе, но использование SQL для производственного веб-приложения является гораздо лучшей идеей и, честно говоря, сделает вещи более простыми.

Переходя за пределы этих «сериализованных данных», есть серверы хранения ключей, хранящиеся в памяти. Такие вещи, как Memcached и Redis.

Но, чтобы вернуться к моему предыдущему моменту, если у вас нет веских оснований не использовать SQL, вы делаете только труднее.