можно еще FactoryGirl.build_list заюзать

build_list немного для другого же, не?

ну т.е. оно для тестов

это же фабрика. Фабрика создает объекты

какой-то конкретной привязки к env в принципе же нет

фактори герл рекомендуют подрубать как-то так gem 'factory_girl_rails', groups: [:development, :test]

ну и билд_лист же создаёт на основе фабрики в factories, а мне нужны пустые объекты

FactoryGirl.build_list(5. :model) == 5.times{ Model.new }

ну не

точнее почти. лист метод еще завернет в array

не ?)

фабрика из factories юзается, без фабрики оно в принципе смысла не имеет

не то в общем ? я просто помню в джанге была такая штука которая генерила заданное количество объектов пустых в конец связи has_many на форму

ничего не понял

фабрика из factories юзается, без фабрики оно в принципе смысла не имеет

ну смотри

в общем либа тебе предоствляет метод чтобы строить объект. Я не понимаю, почему ты думаешь что это можно юзать ТОЛЬКО в определенном env

смотрю

объект строится на основе фабрики, которая определяется в factories/name_your_model без привязки к родительской модели

т.е. на основе фейковых данных(или хардкоренных в той самой фабрике)

Ребят, а как сделать 5 объектов в релейшене? Т.е. мне надо @associations = @city.regions.build(5) и в associations 5 регионов пустых

а возвращаясь к оригинальному вопросу, нужны пустые объекты, которые привязаны к родительской модели

ты можешь trait написать для этого случая и передать city как аргумент. btw всего лишь альтернатива 5.times. Но если это всего лишь 1 раз тебе в проекте понадобится, то можно 5.times заюзать и не парится

ладно

ты можешь trait написать для этого случая и передать city как аргумент. btw всего лишь альтернатива 5.times. Но если это всего лишь 1 раз тебе в проекте понадобится, то можно 5.times заюзать и не парится

нельзя использовать фабрики в рабочем коде

why not ?

а возвращаясь к оригинальному вопросу, нужны пустые объекты, которые привязаны к родительской модели

5.times { создать_5_пустых_объектов Ъ

why not ?

потому что фабрики не для этого фабрики могут создавать объекты со своей логикой отличной от бизнес флоу

они могут какой угодно объект тебе создать

это не ответ на вопрос

как и по бизнес флоу так и нет

в бизнес флоу вполне свои конкретные аргументы обычно зачем build заменять фабричным build?

это всего лишь инструмент

да, но к нему понятие production ready не применимо

он не для этого

у них прям в readme написано

не юзайте в проде ?

это же просто фабрики

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

а если мне надо наделать таких объектов несколько в разных учатсках кода?

я заюзаю паттерн фабрика

я могу свои poro написать

или заюзать либу

несколько.times do

причем тут микроскоп ?

это метафора, это такой литературный прийем

механику твоего литературного приема я понимаю, спасибо что уточнил

неуместность сравнения, вот это не ясно

у них прям в readme написано

да

неуместность сравнения, вот это не ясно

уместно ведь

group :development, :test do gem 'factory_girl_rails' end

прямо вот тут https://github.com/thoughtbot/factory_girl_rails

где ?

https://github.com/thoughtbot/factory_girl_rails#configuration

вообще нет слова production

именно, потому что гем подрубается в группы :development и :test

шли бы вы в https://telegram.me/ruby_talks

https://github.com/thoughtbot/factory_girl

а здесь не слова про env

ладно, я не хочу дальше спорить на эту тему.

только на руби

есть подборка прям заготовок

В юзании рельсового enum есть какие-нибудь "фу"? Может не рекомендуется его пользовать или ещё чего?

если что-то в рельсах есть и оно не deprecated — можно смело юзать

Енум юзай ток с хэшем

Есть одна херня - в базе числа хранятся. Поэтому если какой-то элемент перечисления из середины удаляешь, придется апдейтить в базе все. Мб сейчас уже изменили это, давно им не пользовался

Лучше будет, иначе там ключи при удалении смещаться будут

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

ERROR: S client not available

Ну в целом хелперы которые енумы дают перевешивают то что выше написал

aasm/sm vs enum я за aasm/sm

контролировать проще

aasm я считаю для случаев чуть посложнее простых енумов, но опять ж имхо

рельсы vs руби я за рельсы

aasm я считаю для случаев чуть посложнее простых енумов, но опять ж имхо

да однако енумы какраз используют чаще всего для описания состояния объекта

если переходы есть, то конечно автомат нужен

Ну хз, я часто юзал просто для фильтрации

например?

я старый просто, забыл уже многое

Да, вот как раз без логики перехода

Ну там положение объекта - верх, низ, лево право

aasm лишнее тут будет

я просто строку пишу в таком случае

и в логах видно что where left а не where 2

с енумом удобно obj.state.all

один плюс? :)

валидации не надо писать :)

Если добавлять атрибуты к енум в процессе потом проблемы будут какие-то?

Если добавлять атрибуты к енум в процессе потом проблемы будут какие-то?

а зачем он вообще?

У меня в модели несколько скоупов для разных статусов булевых, думал вот может их на енум поменять.. Какие будут минусы при этом?

Первый раз наткнулся на енум просто думаю вот как применить можно и что это даст ±

Есть одна херня - в базе числа хранятся. Поэтому если какой-то элемент перечисления из середины удаляешь, придется апдейтить в базе все. Мб сейчас уже изменили это, давно им не пользовался

enum lala: { a: 1, b: 0 }

Enumerize гем ниче так, но он прибит к AR емнип

aasm/sm vs enum я за aasm/sm

но это же разные вещи

которые вообще ортогональны

state machine / acts_as_state_machine?

нет, стейт машина и енум

т.е. разные инструменты для решения разных задач

если нет логики переходов между состояниями, то конечный автомат нафиг не нужен

например, если статьи бывают разных типов

и с одного типа на другой не переходят никогда