кароче: нет тестов - нет камней, нет камней - нет дворца, нет дворца - нет дворца

в before_save она уже по идее сохранена если autosave: true

кофейная гуща это не про рельсы

кароче: нет тестов - нет камней, нет камней - нет дворца, нет дворца - нет дворца

ах, любимый мой tdd шник

да. в общем autosave: true это обычный before_save

в котором она и сохраняется

посколькоку коллбэки выполняются в порядке их определения

это не я придумал я могу себе позволить не писать тесты за это страдаю иногда однако, умный человек, не будем показывать пальцем, хотя это был Тимофей Цветков сказал: "Или вы на столько умны, что пишите тесты, или вы не столько умны что не пишите тесты"

то в следующем before_save ее уже видно

то в следующем before_save ее уже видно

ничего не очевидно

Тима Цветков, не знаю его. Кто такой?

одна из старых-стырах марсиан

еще тех

а щас я слышал там плохо не?

там нет цветкова - там плохо

там все может быть зашибись, но цветкова нет

везде, где нет цветкова, плохо

он твой кум или ты поклоняешься ему?

поклоняюсь

он можетбыть уже не торт, но воспоминания еще живы :)

"Есть множество гемов, которые чуть иначе решают одни и те же задачи. С разным синтаксическим сахаром, с разной эстетикой кодирования. Выживают лучше это хорошая стратегия, но не когда «мусора» становится очень много. В Питоне есть библиотеки, которые развиваются и поддерживаются годами, есть проекты, где авторы (к большому сожалению) умерли, но библиотеки все равно активно поддерживаются и развиваются. С руби, когда смотришь на гем, в первую очередь идешь на гитхаб и смотришь сколько людей поддерживает гем, как часто в него коммитят и нередко оказывается, что лучше написать свое, чем использовать гем, который в любой момент могут перестать поддерживать или уже почти перестали поддерживать, ибо любая внешняя зависимость с плохой поддержкой — потенциальная проблема для проекта, который не умрет завтра, послезавтра и в ближайшие несколько лет совершенно точно."

ну ок

тока давайте разберем по слогам

ну неплохая цитатка от него

в питоне нет гемов которые написал какой-то урод и перестал поддерживать?

ну неплохая цитатка от него

плохая

На RailsClub последнем был доклад Сергея Долганова из Марсиан.. как раз по поводу того как определить матюрность гема и его production ready

и вот они написали такую штуку ossert https://github.com/ossert/ossert

понты

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

интересный, но понты

он есть онлайн

ну как скажешь)

по таким метрикам у меня закрытый core-gem супер-пупер

я не буду говорить какое это штако на самом деле

по каким - таким? Я насколько понял они оценивают rubygems, github, SO..

И щас еще хотят еще добавить reddit

Opened and Closed Issues Opened, Merged and Closed PRs ... Releases Count Last Release Date Commits count since last release Amount of changes each quarter Stale and Total branches count Это все плюсы

Opened and Closed Issues Opened and Merged PRs Releases Count Downloads divergence Downloads degradation per release (Comes later) Stale Branches Count это все плюсы

по всем метрикам кроме Opened non-author Issues, "with author comments" and total count

у нас плюсы

только гем никто не видел и никто о нем не знает, но он публичный

там видимо в доке не все

https://github.com/ossert/ossert/blob/84e455dbff69c41264bb57b4d24a32b67594d6cc/lib/ossert/fetch/stackoverflow.rb

Не думаю что у закрытого гема будет много осбуждений на SO

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

я предлагаю свернуть дискуссию, а то ojab нас забанит

ок )

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

ну, то есть, допустим admin_level по дефолту должен быть 0, можно сделать дефолтное значение для колонки

но хотелось бы именно на уровне приложения, вешать на колбек after_create приватный метод и делать?

прозреваю что ты хочешь как минимум before_create, чтобы значение попало в базу

after_initialize

а, понял

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

но вообще это стоит делать на стороне базы

ну, а если перенос будет?

а, ну хотя дефолт останется там

на стороне базы - это в миграциях ведь не будете перенос делать без миграций?

after_initialize

это не позволит создавать записи с другими admin_level

да, все

(через Model.new(admin_level: :whatever))

не, ну можно, но сомнительная радость

def initialize(attrs) super(attrs) self.admin_level = 0 if admin_level.nil? end

да мне нужно, чтобы в базу писало 0

ERROR: S client not available

коллбеки - последний рубеж

почему не сделать это на уровне базы если тебе так нужно ставить дефолт если он не задан? Зачем городить эту фигню?

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

то что у поля стоит дефолт у енума?

это такая жестокая размазанность?

то что у поля стоит дефолт в базе, а не в приложении

и так в 100500 таблицах

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

и что?

да, инициалайз удобнее и читабельнее

а так в приложении куча Г в виде калбеков и прочей фигни

да нифига

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

и используй только его

def initialize(attrs) super(attrs) self.admin_level = 0 if admin_level.nil? end

initialize(*args) и у super аргументы можно не указывать. Ну и ||=

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

foreign_key — тоже бизнес логика или уже нет?

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

и какие факторы в пользу того, чтобы их не юзать?

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

я вижу только один - большая бд которая на один сервер не помещается

иначе стоит юзать я думаю

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

гигом больше, гигом меньше

причем тут это

есть базы которые не влазиют на один сервак

и там твои fk и триггеры и джойны сразу идут по бороде

да, при распределенной бд fk не заработают

Всем привет. Такой вопрос. Может кто сталкивался с проблемой при миграции в случае использования Postgres schema? Т.е при использовании одной базы данных но разных схем, миграция зависает в определенный момент на комите.

ну на сколько я помню там есть свои решения для маштабирования если так

чет вы дичь какую-то разводите - дефолт в конструкторе ставить

тогда может ну нахуй вообще миграции выкинем, они ж к бизнес-логике не относятся

Всем привет. Такой вопрос. Может кто сталкивался с проблемой при миграции в случае использования Postgres schema? Т.е при использовании одной базы данных но разных схем, миграция зависает в определенный момент на комите.

В приложение несколько схем используется? В database.yml для них несколько БД прописано?