номер

ну вот тэг

просто если из середины кейс класса удалить поле, то нумерация съедет. и при десериализации все развалится в труху

просто если из середины кейс класса удалить поле, то нумерация съедет. и при десериализации все развалится в труху

вот я про это

ну так и все про это

не очень понятно нафига вообще протобаф, если схема не сдалась

How can we solve this? Well, we need to give a number to every member of the enum. That’s why PBDirect has a Pos trait. The Pos trait can be used to indicate the position of an object into the enum. sealed trait PhoneType extends Pos object PhoneType { case object Mobile extends PhoneType with Pos._0 case object Home extends PhoneType with Pos._1 case object Work extends PhoneType with Pos._2 }

велосипед какой-то

ну да ) сразу начинается течь

со всех щелей )

но это только для Enum ов

StaticAnnotation поди зашли бы

В общем, https://github.com/sksamuel/avro4s

А кто нибудь реально юзает Avro? У меня ощущение что оно пушится Confluent, но особо вне их стека не используется. Или не там смотрю )

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

и у меня используется ¯\_(ツ)_/¯

в хадуповском стеке может быть профит, потому что всякие HBase и Hive умеют понимать эти схемы

Иметь два ADT ?

Не надо, обычно протобаф юзается внутри, и там версионность нах не сдалась. Да и добавить поле не проблема

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

https://github.com/databricks/spark-avro

Не надо, обычно протобаф юзается внутри, и там версионность нах не сдалась. Да и добавить поле не проблема

Ну надо гарантировать, что все юзают определения одной версии

Ну надо гарантировать, что все юзают определения одной версии

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

@gurinderu привет, а такое видел/пробовал использовать https://github.com/btlines/pbdirect ? там коты и шейплез

Не юзал, но может гляну

Вообще выглядит странно, потому что в protobuf3 нету optional)

конечно нету, потому что все и так опшнл

Угу)

а-а, ты про схему из примера

Вообще не вижу смысла в либе без схемы, ведь с другого языка эту Либу не поюзать. Хотя может для тестирования удобно

а-а, ты про схему из примера

Угу

Вообще выглядит странно, потому что в protobuf3 нету optional)

да там еще oneOf не очень поддерживается

Тем более)

Кстати, а никого не бесит что scalapb генерирует optional?)

меня вообще скалапб бесит)

Гыгы

меня вообще скалапб бесит)

Ну в последнем релизе вроде более менее все стало, не?

да

да и было не оч страшно, так что норм

А как ты решаешь проблему генерации required полей?)

А в scalapb кроме генерации кейс классиков еще и генерятся клиент с сервером?

А в scalapb кроме генерации кейс классиков еще и генерятся клиент с сервером?

Стабы? Ага

А как ты решаешь проблему генерации required полей?)

requried deprecated

Стабы? Ага

почему стабы? их нельзя использовать для отправки сообщений? я не шарю в этом

requried deprecated

Не, его просто нет в protobuf3. Но вот понимаешь, я точно знаю какие поля мне нужны и постоянно оборачивать их в some бесит

почему стабы? их нельзя использовать для отправки сообщений? я не шарю в этом

Они так там называются)

Хз почему, первый раз тоже удивился

И этот клиент который там есть - насколько он навороченный? там есть какие-то гарантии доставки сообщений или что-то такое?

Не, его просто нет в protobuf3. Но вот понимаешь, я точно знаю какие поля мне нужны и постоянно оборачивать их в some бесит

напиши функцию a , которая оборачивает в сам , не ленись

напиши функцию a , которая оборачивает в сам , не ленись

Лол

Так то проще написать Some(v)

а если v null?

И этот клиент который там есть - насколько он навороченный? там есть какие-то гарантии доставки сообщений или что-то такое?

Клиент обычный джавовый, я вот юзаю тот, что с нетти

а если v null?

Ну я т знаю что он не null

И этот клиент который там есть - насколько он навороченный? там есть какие-то гарантии доставки сообщений или что-то такое?

Гарантии в grpc впринципе нету) самому придётся делать)

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

Ну я т знаю что он не null

короч ты делаешь то , за что Нада отрывать руки!

ты пытаешься писать код, который не проверит компилятор

короч ты делаешь то , за что Нада отрывать руки!

В смысле ?

и который может в рантайме упасть если кто-то в mq запишет плохой протобаф

У меня есть Json, который определяется строго по правилам и как бы он по валидации упадёт, если поле null

Тут компилятор ну никак не поможет)

В смысле ?

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

Ну ага, два раза )

У меня есть Json, который определяется строго по правилам и как бы он по валидации упадёт, если поле null

я с тобой не согласен , опшонал это хорошо !

ты слишком долго сидел в Раст чатике

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

ERROR: S client not available

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

Some

Ты понимаешь , что это тупо?)

нет не тупо

Обоснуй

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

или ещё ерунда какая

вроде похожий спор был у ребят в гугле когда они решили выкидывать required

типа а пусть все всегда будет опшинал, так проще версионировать

но меня это раздражает)

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

Вот вот

но писать патматы экстракты приходится и это бесит

Я не против опшинала везде, но оставьте вы required

Вообще конечно можно на уровне генератора это решить

как проводить миграцию версий при использовании подобной штуки?

я либой этой не пользовался, но думаю что так: никогда не менять поля местами, не удалять поле, только добавлять, а если у тебя event sourcing, то просто создаешь новый кейс класса эвента и сохраняешь а старый никогда не меняешь

я либой этой не пользовался, но думаю что так: никогда не менять поля местами, не удалять поле, только добавлять, а если у тебя event sourcing, то просто создаешь новый кейс класса эвента и сохраняешь а старый никогда не меняешь

ну этож вообще дикий костыль

кстати, говоря об event sourcing-е, со временем аггрегат начинает обрастать кучей optional-полей которые на самом деле пристутсвуют во всех новых ивентах, но оставлены опциональными для обратной совместимости. Я думал над решением, и ничего лучше как сделать две версии DTO пока не придумал. новые ивенты мапятся в новую версию, старые в старую. Может есть получше способ избавится от option?

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

кстати, говоря об event sourcing-е, со временем аггрегат начинает обрастать кучей optional-полей которые на самом деле пристутсвуют во всех новых ивентах, но оставлены опциональными для обратной совместимости. Я думал над решением, и ничего лучше как сделать две версии DTO пока не придумал. новые ивенты мапятся в новую версию, старые в старую. Может есть получше способ избавится от option?

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

кстати, говоря об event sourcing-е, со временем аггрегат начинает обрастать кучей optional-полей которые на самом деле пристутсвуют во всех новых ивентах, но оставлены опциональными для обратной совместимости. Я думал над решением, и ничего лучше как сделать две версии DTO пока не придумал. новые ивенты мапятся в новую версию, старые в старую. Может есть получше способ избавится от option?

http://files.movereem.nl/2017saner-eventsourcing.pdf монументальное по теме миграций, реально есть техники, из которых можно выбрать

о круто, ща посмотрим)

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

ага, только ивенты

но старые ивенты не содержат нужных данных

ну я бы так же сделал) два разных дто + общий трейт

поэтому везде опшны

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

но старые ивенты не содержат нужных данных

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

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

реально дарк сайд)

http://p.migdal.pl/2017/01/06/king-man-woman-queen-why.html

че делается-то.. че делается!!

tldr: