Как в uml указать тип поля json строки?

Question

[historydev]

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



Как мне указать что здесь будет строка json содержащая массив строк?

Answer 1

[Василий Банников]

Покажи хоть код свой что и куда ты там запихнуть пытаешься.

В plantuml в "тип" можно произвольную строку вписывать. Можешь хоть русским языком написать "json с полем такого-то типа"

UPD: скорее всего тебе нужно что-то типа:

@startuml
interface Chat {
  id: string
  type: ChatType
  name: string
  participantCount: int
  invitationLink: string
  isAllowAccessByInvitationLink: bool
  isAllowAccessInvitations: bool
  isInArchive: bool
  createadAt: Timestamp
  updatedAt: Timestamp
}



enum ChatType {
  Chat = "chat" // чат
  Community = "community" // сообщество
  Event = "event" // событие
  Course = "course" // курс
}
Chat -> ChatType
@enduml

Comments

[historydev]

Код здесь роли не играет, русским не хотелось бы, классовая диаграмма как-никак

[Василий Банников]

Владимир, раз это классовая диаграмма, то каким боком тут MySQL? Просто добавь на диаграмму класс, который представляет из себя внутреннюю структуру этого json-объекта и ссылайся на него.
+ Для кого ты эту диаграмму рисуешь?

[historydev]

Василий Банников, Класс здесь перебор, скорее нужен тип или сущность, я бы выбрал тип, поищу как его в plantuml создать.

Не рисую, а пишу, рисовать пробовал, бред какой-то.

Больше пишу для себя и с ним ещё один человек работает, пишет доки для api.

[historydev]

Василий Банников, Mysql я упомянул скорее как доп. инфу, типа зачем мне это нужно, чтобы был какой-то контекст.

[Василий Банников]

Владимир, класс - это и есть тип, лол. Ну можно ещё интерфейс сделать.

Не рисую, а пишу, рисовать пробовал, бред какой-то.

Рисуешь буквами получается. Вопрос тут был не про рисование, а про потребителя.
Если для себя, то почему бы не сделать так, как тебе удобнее будет читать схему?

[Василий Банников]

Владимир, обманул немного. Вообще визуально в plantuml все "типы" выглядят одинаково - отличие только в букве.
Если хочется отойти от классов и сделать типа плоский тип без методов и приватных полей - это похоже на struct.

@startuml
abstract        abstract
abstract class  "abstract class"
annotation      annotation
circle          circle
()              circle_short_form
class           class
diamond         diamond
<>              diamond_short_form
entity          entity
enum            enum
interface       interface
protocol        protocol
struct          struct
@enduml

[historydev]

Василий Банников,

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

Да и это хорошая практика, целиться в понимание твоей работы, человеком как минимум соответствующего твоей квалификации.
В портфель кинуть не стыдно.

Я ещё убрал борщ где разжовывал всё до примеров запросов на определённом языке.
Потом посчитал бредом, т.к. это формат документации, а не uml и почистил всё.

Если я буду делать как мне удобнее сейчас, что будет если это удобнее изменится через неделю? - переписывать, а мне лень :)

Я скрупулёзно всё делаю, иногда трудно удержатся от излишних деталей.
Мне человек сказал что ещё немного и я в 3d этот uml буду делать)

[historydev]

Василий Банников,

Не совсем - если использовать стили, можно группировать сущности вообще любым способом и букву тоже менять можно, правда только одна помещается.

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

Что-то вроде типа в ts: type jsonStr = '["123"]'

[Василий Банников]

Владимир,

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

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

Посмотри лучше в сторону C4 диаграмм - там также есть и ответ, почему UML в реальном мире тупо не работает.
И вот если говорить в терминах C4 Model - тебе нужен уровень "Container diagram", ну максимум в редких случаях - "Component diagram", а ты пытаешься сделать "Code diagram", который устаревает в течение одного дня активной разработки.

Диаграмму по схеме базы данных тебе в один клик какой-нибудь Datagrip и так сгенерит.

Если я буду делать как мне удобнее сейчас, что будет если это удобнее изменится через неделю? - переписывать, а мне лень :)

Вот мы и пришли к решению - тебе просто не нужен UML Class diagram.

Мне человек сказал что ещё немного и я в 3d этот uml буду делать)

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

PS: можешь скинуть картинку?

[Василий Банников]

Владимир,

Не совсем - если использовать стили, можно группировать сущности вообще любым способом и букву тоже менять можно, правда только одна помещается.

Даже больше скажу - можно вообще кастомные прямоугольнички рисовать.

Что-то вроде типа в ts: type jsonStr = '["123"]'

Ну так и напиши тогда:

class MyClass {
  {field} +json_column: TEXT ({ "participantReaders": string[] })
}

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

PS: в отрыве от диаграмм, но схема БД какая-то стрёмная у тебя получается.
1. Это легко можно реализовать через связь 1-many
2. MySQL это не постгрес и она сильно медленнее работает с json-ами, что станет проблемой, если ты захочешь использовать эту колонку в каких-нибудь фильтрах. Да и никакого контроля целостности не будет.

[historydev]

Василий Банников,

По моей задумке никакого кода не будет, пока не будут внесены изменения в uml.

А это на сугубо моей практике рабочий сервис с первого раза, по чёткой инструкции.
Если в инструкции нет ошибки разумеется.

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

[Василий Банников]

Владимир,

По моей задумке никакого кода не будет, пока не будут внесены изменения в uml.

А это на сугубо моей практике рабочий сервис с первого раза, по чёткой инструкции.
Если в инструкции нет ошибки разумеется.
В добавок если баг появился, его можно вычислить на уровне абстракции, а не дебажить сидеть.

Oh my sweet summer child ...

Могу только пожелать удачи тебе :D

Ну и как мысль - если эта визуальная инструкция будет на столько подробной, что её можно будет однозначно перенести в код, то зачем вообще рабочий сервис руками писать? Делай тогда сразу генератор кода на основе диаграмм.

Кстати, такое уже было раньше и сейчас переживает второе рождение в виде всяких Nocode платформ.
В обоих случаях там дохренище подводных, которые не дают использовать такой подход в сколько-нибудь большом масштабе (более одного человека, который это разрабатывает и поддерживает)

[historydev]

Василий Банников, С картинкой сложности - не за компом.

Ну так и напиши тогда:

Так тоже много букав. Классовая диаграмма не только классы содержит, интерфейсы у меня конкретно в этой. Одни интерфейсы:
interface A { participantsReaders: string[] }

Хочется отдельный тип максимально короткого формата, то есть вынести string[] + указание что это json допустим в кастомный тип jsonArray и получить вот такое:

interface A { participantsReaders: jsonArray }

[Василий Банников]

Владимир,

Хочется отдельный тип максимально короткого формата, то есть вынести string[] + указание что это json допустим в кастомный тип jsonArray и получить вот такое:

Ну напиши так тогда.

[historydev]

Василий Банников,

Ну и как мысль - если эта визуальная инструкция будет на столько подробной, что её можно будет однозначно перенести в код, то зачем вообще рабочий сервис руками писать?

Затем, что все свои ошибки ты допустишь на ней и не придётся потом рефакторить возможное говно, которое можно заметить на uml.

Это первое.

Второе - uml не привязывается к языку - соответственно если что-то не устроит в проде на текущем стеке, его можно супер быстро переписать на что угодно.

В третьих - никакого кода, для понимания работы сервиса. Быстрое введение новичков в курс дела. Изучить синтаксис uml можно за пару вечеров, а вот стек проекта - нет.

Генераторы статики - это говно, ты прав.

Это доказали ещё в 2010 или когда там ucoz, wix и прочие платформы для мамкиных пиратов нарисовались.

Я не говорю о том, что тебе нужно чуть-ли не работу функции описать.

Здесь скорее i/o интерфейсы, а уже как ты там это кодировать будешь и на чём - роли не играет.

Условно функция А принимает аргумент Б и возвращает данные типа В.

[historydev]

Василий Банников,

Изучить синтаксис uml можно за пару вечеров, а вот стек проекта - нет.

Это кстати демонстрируют лидирующие на рынке компании, их всех сейчас обобщили в какое-то словечко по первым буквам каждой.

Проходят люди собес, их перевозят - тестовый период не проходят, не успевают вникнуть в проект и их вышвыривают. Ещё и затраты покрыть потом должны.

[Василий Банников]

Владимир,

Затем, что все свои ошибки ты допустишь на ней и не придётся потом рефакторить возможное говно, которое можно заметить на uml.

Ага, и будешь рефакторить uml, у которого инструментов для рефакторинга нет.

Второе - uml не привязывается к языку - соответственно если что-то не устроит в проде на текущем стеке, его можно супер быстро переписать на что угодно.

Смешно)

В третьих - никакого кода, для понимания работы сервиса. Быстрое введение новичков в курс дела. Изучить синтаксис uml можно за пару вечеров, а вот стек проекта - нет.

Но ведь стек проекта и то как схема в код маппится всё равно нужно изучить.

Здесь скорее i/o интерфейсы, а уже как ты там это кодировать будешь и на чём - роли не играет.

Условно функция А принимает аргумент Б и возвращает данные типа В.

И зачем тебе тогда UML?
Для io-интерфейсов уже придуман grpc, graphql и ещё куча разных других schema-first инструментов для описания сервисов.

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

[historydev]

Василий Банников,

Ну напиши так тогда.

А как "так"? - я пока не вижу куда это вынести можно

[Василий Банников]

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

Можешь мне в телеге написать, чтобы потом показать вживую?

[Василий Банников]

Владимир, что "это"?

[historydev]

Василий Банников,

Затем что я не цифра в таблицах какого-то монополиста и всё что я знаю, это то что я нашёл сам.

Мне не с кем пообщаться, у меня нет связей в it, я одиночка.

Я с радостью изучу что-то новое, но сраные стартапы душат меня своими дедлайнами.

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

Да, можем завтра списаться в телеге, я с радостью пообщаюсь и приму моменты, где я не прав.

Можно какую-то фигню набросать, по типу "послал привет - получил ответ".
Чтобы на часы не растянулось.

[historydev]

Василий Банников, "Это" - синтаксис по типу type A = string[], в plantuml