и всякие json поверх http2 тоже будут подарком

Так … И чего? :)

с точно такой же сложностью

Сделать рест поверх http2 и радоваться жизни ? :)

Так … И чего? :)

я о том,что всякие текстовые протоколы поверх http2 становятся точно такими же нечитаемы как и какой-нибудь msgpack/cbor поверх tcp.

Ну да, есть такое.

Почему в rest нет массовых операций? Даже отдельный метод иногда предлагают для этого использовать - patch.

Почему в rest нет массовых операций? Даже отдельный метод иногда предлагают для этого использовать - patch.

а как в нем сделать 10к разных операций разом?

а как в нем сделать 10к разных операций разом?

http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

> a sequence of operations to apply to a JSON document Не знал что это есть в RFC

Спасибо

{ "op": "test", "path": "/a/b/c", "value": "foo" }, { "op": "remove", "path": "/a/b/c" }, { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, { "op": "replace", "path": "/a/b/c", "value": 42 },

вообщем-то, то о чем я говорю

вектор из { op, args }

{ "op": "test", "path": "/a/b/c", "value": "foo" }, { "op": "remove", "path": "/a/b/c" }, { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, { "op": "replace", "path": "/a/b/c", "value": 42 },

А потом хлоп, и нам надо чтобы это ещё умел наш рест-фреймворк. А ещё нам вообще то не ресурсы и их методы нужны, а rpc, потому что поиск, фильтрация, транзацкционные апдейты нескольких сущностей.

Вообще, идеальный апи должен быть событийным ?

Транзакционные апдейты нескольких сущностей разве в rest не вписываются? Берешь коллекцию, в которую входят все нужные сущности и работаешь с ней как с отдельным ресурсом.

Вообще, идеальный апи должен быть событийным ?

так я бы взял logux, но ещё год ждать

а у пониорм оказывается до сих пор нету миграций о_0

и зачем он тогда нужен

Транзакционные апдейты нескольких сущностей разве в rest не вписываются? Берешь коллекцию, в которую входят все нужные сущности и работаешь с ней как с отдельным ресурсом.

Разные сущности - это разные коллекции

и зачем он тогда нужен

Никто не мешает аккуратно писать миграции руками в South. Есть мнение, что так даже надежнее

а, я почему-то думал что south это исключительно джанго-история

тогда да, может и норм

а, стоп. >> South is a tool to provide consistent, easy-to-use and database-agnostic migrations for Django applications.

Разные сущности - это разные коллекции

Почему? Нет же таких ограничений. Это общепринятый метод, чтобы проще было фреймворки писать.

а, стоп. >> South is a tool to provide consistent, easy-to-use and database-agnostic migrations for Django applications.

гг, вот это я ща удивился, что у ребят до сих пор мигрейшн тулов нет

(я про пони)

да, я тоже. Это дилбрейкер очевидный, и ишью висит годами

алембик не заюзать без алхимии, south без джанго. Пониорм в пролёте, к нему нет инструмента миграций даже стороннего

поправьте, если вру

ну, значит, алхимия. Во фласке даже есть какая-то обёртка поверх алембика, значит в eve её можно будет использовать

а, стоп. >> South is a tool to provide consistent, easy-to-use and database-agnostic migrations for Django applications.

Ну, там можно не писать приложение на джанге

Ну, там можно не писать приложение на джанге

разве? о_0 Это как? Он же на Django API весь написан?

везде пишут что сауф без джанги не работает

Почему? Нет же таких ограничений. Это общепринятый метод, чтобы проще было фреймворки писать.

Я не понял. Есть юзер и аватар. Надо сохранить картинку, её имя и слинковать с юзером в одну транзакцию

да, я тоже. Это дилбрейкер очевидный, и ишью висит годами

Они пишут сейчас прямо. Пару недель назад писали об этом в своём чате

интересно :)

везде пишут что сауф без джанги не работает

Ну, кто тебе мешает писать модели джанги только для South?

дублирование кода будет в таком случае

хорошего ещё меньше, чем писать миграции руками

кому любопытно, нашёл их относительно свежий доклад (от октября 2016) https://conf.python.ru/pony-orm-migracii-mega-anons/

Я не понял. Есть юзер и аватар. Надо сохранить картинку, её имя и слинковать с юзером в одну транзакцию

Получается, что это ресурс avatar с embedded ресурсом image. Так все кучей и передавать.

А пользователя или в теле запроса передать или по url вычислять /api/username/avatar

Получается, что это ресурс avatar с embedded ресурсом image. Так все кучей и передавать.

А как это принимать? Я к тому, что это придётся писать руками в любом фреймворке. И это все ломает стройность апи

Проблемы индейцев методологию rest не волнуют :D Если нужен именно rest с media types и прочими радостями, тогда придется реализовать. А если по факту нет необходимости применять именно rest, то к какому-то своему согоашению прий ти, которое не портит стройность api.

а у пониорм оказывается до сих пор нету миграций о_0

чем ponyorm лучше peewee?

алембик не заюзать без алхимии, south без джанго. Пониорм в пролёте, к нему нет инструмента миграций даже стороннего

А почему алембик без алхимии не может? Там же можно вообще что угодно в коде миграции писать, хоть напрямую sql дергать

чем ponyorm лучше peewee?

я не знаю ничего толком про peewee, кроме их фабулы

я знаю чем мне мог бы быть полезен/удобен пони

А почему алембик без алхимии не может? Там же можно вообще что угодно в коде миграции писать, хоть напрямую sql дергать

так он же цепляется к объекту алхимии на этапе инициализации

и ему нужны модели алхимии, чтобы собрать мета-информацию с них

авторы пони сказали что прям скоро-скоро релиз, альфа-версия на след неделе https://twitter.com/amalashkevich/status/816296663077834753

пожалуй возьму пони всё же. Благо действительно на раннем этапе миграции не нужны

в алхимии слишком много всего надо делать руками, мне это сейчас только мешать будет. Даже тот же алембик надо конфигурять

А через какое время планируешь проект закопать?

а что не так? =)

Или положить на полку там. Я про планируемый срок разработки и поддержки

аа. Так неясно сейчас, взлетит ли. Вероятно вообще не планирую закапывать

Прямо всю жизнь тянуть будешь?

ну всю нет конечно.) всю жизнь ничего не может продлиться

но несколько лет например может, наверное

ERROR: S client not available

но это best-case scenario

а почему ты спрашиваешь? о_0

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

А, ага

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

https://a248.e.akamai.net/secure.meetupstatic.com/photos/event/1/8/b/6/highres_457266326.jpeg

https://www.meetup.com/spbpython/events/235417251/

Забронировал?

Забронировал?

позвонил сейчас. забронировал. :)

Начнём пораньше. В шесть вечера.

молодцы что кдпв заделали :)

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

Если взлетит нормально, можно хоть раз в пол года переписывать кусками. Главное изначально всё модульно делать

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

и раз в полгода переписывать это какой-то дикий оверхед

Если взлетит нормально, можно хоть раз в пол года переписывать кусками. Главное изначально всё модульно делать

ну вот да

- как вы напишете проект х? - берём руби и фигачим как бог на душу положит. Как взлетело, поднимаем раунд, на эти деньги берём CTO с командой и они всё переписывают нормально

универсальный ответ если вас просят убер/аирбнб/твиттер запроектировать на собеседовании

- как вы напишете проект х? - берём руби и фигачим как бог на душу положит. Как взлетело, поднимаем раунд, на эти деньги берём CTO с командой и они всё переписывают нормально

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

нафиг вообще идти в ранний стартап, если ты не собираешься там потом стать этим самым CTO?

ради атмосферы? =)

но ладно, ты прав.

это больше хохма была

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

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

хороший термин! "смузи-технология"

Фух, вроде отпустило)

Судя по переписке Дима реально выбрал стек смузи-технологий) graphql, ponyorm )

Судя по переписке Дима реально выбрал стек смузи-технологий) graphql, ponyorm )

митя* :)

а как ты думаешь? конечно выбрал

В оффлайне же Митя )) а здесь Dmitry ))

Dmitry полное, митя краткое. всё вполне консистентно