Спасибо что помогаете, но я пока не понял, как лучше сделать.

behavour позволяет сделать так?

%A{x: 1, y: 2, super_field: 123123}
%B{x: 1, y: 2, super_field: "stroka"}
%С{x: 3, y: 4, super_pooper_field: ["a", "a"]}

Без дублирования общих частей?

Или вы предлагаете отказаться от этого и довольствоваться голым полем extras?

Паттерн-матчинг чего? Для валидаций?

Если не затруднит, можно в виде кода? Не пойму о чем речь

Общее поле в GenericConncetor: https://gist.github.com/AlexNeyman/98694ceac2d491f136be0fcbaf978191#file-generic_connector-ex-L14
Общий changeset в GenericConnector: https://gist.github.com/AlexNeyman/98694ceac2d491f136be0fcbaf978191#file-generic_connector-ex-L21
Конкретный тип со своими полями и валидациями: https://gist.github.com/AlexNeyman/98694ceac2d491f136be0fcbaf978191#file-special_connector-ex-L4

Общие части написаны один раз, мне это нравится. У My.SpecialConnector общие поля и его собственные поля находятся на одном уровне, мне и это нравится. В GraphQL это разные типы, resolution работает «сам».

Не нравится макрос. Как сделать без макроса?

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

Макросы душу мне не греют, сам хочу без них, но пойму как, чтобы не копипастить дофига.

https://pastebin.com/8DF7tFFY не?

Да, так и надо

Только название модуля можно из типа генерировать

Заменяешь только коннекторы на ExOp дабы не копипастить валидации, пишешь легкий макрос в ConnectorDispatcher дабы не копипастить а юзать apply

только вот про это писал 🙂

Мы заменили механизм диспатчеризации из встроенного в протоколы на самопосный свич-кейс и behaviour. ОК, но не пойму, чем это лучше? Я могу объяснить чем это хуже, субъективно.

И это не отвечает на вопрос: как не дублировать описание common полей и валидаций? У My.ConnectorA один набор полей, а у My.ConnectorB — другой.

Правильно понимаю: предлагаешь не использовать для валидации типа, хранимого в базе, Ecto, а использовать Exop?

Пока ощущение такое: задача легко решается в OOP, в Elixir нет OOP, но я тащу в него OOP. Поэтому, чтобы сделать правильно, нужно сделать менее удобно

В бд тоже нет ООП

Все упирается в то, как ты эти данные хранишь

Ну к примеру вот так - https://pastebin.com/K5dRE08g?

Во, прям как у меня. А если хочется иметь структуру с этими полями и чтобы еще Ecto — потому что почему Exop? мне записать в базу нужно — выйдет совсем как у меня

Я все еще не понимаю, как ты понимаешь тип когда загружаешь из базы

прислали тебе id - 100500

И ты пишеш Repo.get(chto_to, 100500)?

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

Наверное, тут иначе никак