крут

Олсо tfw код вообще понятнее и проще, чем попытки объяснить его на русском.

Было в рельсах из коробки //

@anonymous Покажи! А генерация и типов данных, и CREATE TABLE (да ещё и с миграцией) из деклараций типа нижеприведённой в рельсах есть? ```` Author first_name String middle_name String last_name String ````

@minoru http://apidock.com/rails/ActiveRecord/Relation/find_or_create_by http://guides.rubyonrails.org/migrations.html#model-generators

@anonymous Круто, спасибо. Таки есть в руби ещё что-то кроме хайпа :)

>>> Book.objects.get_or_create(name="Meow-meow", defaults={'author': 'John Doe', 'in_stock': 10}) джанга, либо получает объект, либо создает новый c параметрами в defaults

@partizan Это база. Покажи мне, если интересно, аналоги getByValue и того, что я показал в /T9A.

@minoru что значит "база"? работает с бд? да, а с чем надо? get_or_create это и есть аналог find_or_create, ну а миграции у нас тоже есть: http://south.readthedocs.org/en/latest/tutorial/part1.html

@minoru а getByValue это я там не совсем понял что это, ну типа как Book.objects.get(lang='ru') ?

@partizan Под «базой» я имел в виду, что штука простая и, в принципе, вполне ожидаемо, что любой нормальный язык что-то такое предоставляет.

@partizan Если твой get возвращает первую подходящую запись — то оно. Дополнительные очки, если у вас есть аналог getBy; ему передаётся объект, содержащий все поля, входящие в primary key, и, таким образом, результатов гарантированно не больше одного. В Haskell это проверяется с помощью типов, в Python, наверное, ты просто на меня посмотришь странным взглядом и снова скажешь «get()».

@partizan Миграция засчитывается, да. Блин, дойдёт сейчас до того, что вы меня убедите, что всё то же самое можно писать на любом мейнстримном языке, без потери выразительности :(

@minoru на самом деле так и есть

@minoru мой get и get_or_create возвращает всегда один объект, т.е. ему желательно передавать primary key, если найдет больше - эксепшн. первый попавшийся `Book.objects.filter(name='meow')[0]`, типа так

@partizan Т. е. `получить первый или создать` нельзя? Только эксепшн обрабатывать?

@anonymous ну типа да, впрочем это не так сложно ``` try: book = Book.objects.filter(name='Meow')[0] except: book = Book.objects.create(name='Meow') ``` но такого я никогда не юзал, всегда хватало get_or_create

@anonymous двачую славика

@minoru ну итт вроде простые примеры просто, надо глубже погружаться

@anonymous нет, эксепшн это для get, в `get_or_create` так, как ты описал

@238328 >If multiple objects are found, get_or_create raises MultipleObjectsReturned.

Какое-то ебанатство, если честно, вот этот вот getByValue. Оно что, по всем полям ищет? А что если ты добавишь колоночку "active :: Bool"? Придётся не забыть зарефакторить вот это место? Почему не выбрать явно по полю language (или code или как там).

@238328 >2017 >рубли

@kb Подозреваю, что да, все поля тыкаются в WHERE. При наличии индекса проблемы не вижу, тем более что оптимизатор может взять поля, составляющие PK, и поискать сначала по ним — для ключа наверняка есть индекс. Если добавлю колонку, то рефакторить придётся по-любому; это проблема ADT в общем. Про понимается под «выбрать по полю явно»? Там таблица из одного поля, в котором коды языков.

@minoru Ну, и что будет происходить, если ты добавишь колонку "name"? Подозреваю, или потенциально создашь несколько языков с одинаковым кодом но разным именем, или будешь получать ошибку т.к. индекс и все дела. Но это ведь хуёво, не?

@kb Код сейчас primary key, я не могу несколько записей с одинаковым кодом создать. Куда ты клонишь?

@anonymous (( // логично

@minoru Клоню туда, что твой код начнёт бросать эксепшн и рисовать ошибку. То есть будешь делать ненужные действия по обработке этих ошибок. В случае выборки лишь по нужным колонкам ты не будешь делать ненужную работу и захламлять код ненужной логикой.

@kb Ну и изначально ты хотел вот это: - если запись существует -- вернуть её id А получишь вот это: - если запись существует -- вернуть id или ошибку То есть программа работает не так, как ты хочешь, кароч.

@kb Не начнёт, потому что если я добавлю в таблицу новое поле, то мне придётся и getByValue поменять (потому что тайпчекер скажет, что я передаю в конструктор Language на один параметр меньше, чем требуется). getByValue следует понимать как «найдите-ка мне вот такую строку в таблице». С точки зрения реляционных баз данных это действительно ебланство, считается, что спрашивать нужно по-другому — «найдите-ка мне строчку с вот таким вот primary key». Для этого есть getBy. Я сначала не понял разницы и юзал getByValue потому, что это проще. Сейчас я вообще понял, что делаю лишнюю работу, и переписал вот так: ````haskell insertLanguage language = do result <- insertBy $ Language language case result of Left duplicate -> return $ entityKey duplicate Right key -> return key ````

@minoru Вся суть пользователей статически-типизированных языков: делай хуйню лишь бы компилировалась. // В то время как какой-нибудь питонист бы написал `ensure_by`, которая бы избавила от дублирований логики на каждый чих, и не требовала бы рефакторингов при изменениях моделей.

@kb Потом этот питонист добавил бы в PK ещё одно поле и начал бы получать ошибки в рантайме. Давай не будем начинать здесь этот срачик, ок? Тем более что ты не показываешь мне полный код, а только говоришь о каких-то там функциях. Мне самому за тебя код писать?

@minoru Вот тебе копипаста с стековерфлоу: ``` def get_or_create(session, model, **kwargs): instance = session.query(model).filter_by(**kwargs).first() if instance: return instance else: instance = model(**kwargs) session.add(instance) return instance ``` Используется примерно так: ``` get_or_create(session, Language, code="en") ``` От количества добавленных примари/юник и прочих полей (как и моделей) этот метод меняться не будет.

@kb Окей, getByValue сделали. Что с getBy? Ты можешь написать метод, который будет уверен, что ему передали все поля из PK?

@minoru Что ты имеешь в виду под "будет уверен"? Будет уверен когда?

@kb В compile time.

@minoru пук.

@ulidtko пукнул во время компиляции

@minoru > Ты можешь написать метод, который будет уверен, что ему передали все поля из PK? Блять, у меня (в питоновой части проекта, т.к. я-то как раз пишу процентов 90 на хаскеле) модель строится динамически из базы данных, не то что такие пустяки. А у тебя хаскель проверяет во время компиляции соответствие хаскелевых описаний индексам описаниям внутри БД?

@kb s/описаний индексам/описаний индексов/

@kb Нет. Persistent отталкивается от того, что база создана им же из описания, предоставленного программистом. Проверяется относительно этого описания (причём в основном тайпчекером). Если схема базы почему-то изменится, persistent мигрирует её обратно к той, которую он хочет. А как ты в своём проекте убеждаешься, что после добавления нового поля в PK ты отрефакторил все места, где ты по этому PK что-то выбирал?

@minoru Так же как и убеждаюсь что код выборки вообще вызвался в нужных мне моментах. Вот как ты убеждаешься, что выборка вообще вызвалась?

@kb Но погоди, тот факт, что select вызвался, вовсе не значит, что он вернул единственную запись. Ты добавляешь поле в PK, а выбираешь только по части ключа, следовательно, можешь получить больше одного результата, а get вернёт тебе только первый. При этом ты будешь думать, что выбираешь по PK. Вызывается в нужных случаях или нет можно проверить тестами (не у меня, но в теории). А вот сколько тестов нужно нагородить (и сколько тестовых данных сгенерировать), чтобы покрыть все возможные проколы с выборкой по части ключа?

@kb Да. Заодно научишься не играть часами ;)

@minoru Бывает нужно выбрать первый, бывает нужно выбрать максимум один, бывает нужно чтоб он всегда был один, бывает что нужно чтобы "сумма продуктов в корзине была меньше 1000 долларов". Это уже зависит от того, что тебе нужно.

@minoru Это я к тому что мне вполне может быть нужно выбирать по части ключа. С чего ты взял что обязательно по всему ключу выбирать?

@kb Потому что в этом треде мы обсуждаем не твои требования, а мою ситуацию. В первом посте, по-моему, достаточно чётко описано, что мне нужно чтобы результатов было не больше одного. Так всё-таки, как тестировать? Городить кучу тестов и данных на все случаи?

@minoru Из этого ещё не понятно, что делать если результатов больше или меньше одного, потому не достаточно. Тестировать -- ну я тестирую просто как сценарий общий, т.к. всё равно ж руками будешь потом этот же сценарий кликать (если теста не будет). Ну и потом только то, где не уверен. К сожалению, типы совсем не спасают и не дают "компилируется -- значит работает". Просто разработку, читабельность и поддерживаемость ускоряют.