Выделите обработку аудио в отдельные функции и проверьте каждую по-отдельности. Получение файла - в одну функцию, сохранение - в другую, открытие сохраненного - в третью, преобразование - в четвертую, отправку - в пятую, удаление - в шестую. И т.п.
Каждая функция должна делать только одно.
В идеале еще к каждой функции написать несколько тестов.
Я бы в первую очередь смотрел бы насчет того, реально ли проброшены порты. Я сколько возился с докером, вечно оно не туда смотрит. Не на тот внутренний адрес, или порт уже занят чем-то…
Adamos, да, я упоминал о возможности жениться на собственной бабушке… :/ что для таких случаев делать? «Бабушка» остается на своем поколении, связи у всех указываются как я описал ранее, а в дереве я бы располагал потомство от разных поколений в поколение потомков более молодого из родителей.
В некотором роде костыль, ну а какие варианты еще?
shurshur, я рассуждаю так:
В генеалогической системе брак не является самостоятельным объектом. Это состояние других объектов. Поэтому он никак не может быть узлом.
В юридической или документообороте может быть объект «свидетельство о браке». Но оно не равно браку как таковому. На него можно ссылаться, как на подтверждающий документ состояния брака.
В состоянии брака могут быть два или более человек. Но в любой отдельный момент надо выбрать одного и смотреть его состояние на определенный момент.
Да, могут быть самые загогулистые сочетания, вплоть до женитьбы на собственной бабушке… :/
Но если смотреть с точки зрения одного человека, всё станет просто - две обязательных связи к наверх к предкам, n связей опциональных горизонтально - супруги.
Всё становится просто и одно из другого вытекает.
Для каждой связи ряд доп. атрибутов - начало, окончание (опционально), документы, комментарии.
Одновременно в базе держать дополнительный индекс в обратную сторону (от предков к потомкам), если работа должна быть очень быстрой. Но это уже сахарок, который может привести к замедлению во время перестроения индексов, снижению консистентности, в общем накладки будут.
Предлагаю подробнее описать конечную цель всего этого. А то выглядит как «мне в багажник Запорожца надо положить два кубометра дров и еще самосвал картошки. И уехать со всем этим»
Впрочем, можно оставить и так, но тогда высокий шанс, что модераторы удалят вопрос по причине «вопрос необходимо конкретизировать».
Мне кажется, вы пытаетесь скрестить несколько нескрестимых сущностей.
В любой момент времени мы должны рассматривать конкретного человека.
И в этот момент он - центр и опора, а остальное должно к нему подтягиваться - предки, потомки, супруги, сиблинги - всё это вокруг него, главного в данный момент.
Тогда у вас в любой момент есть два прямых предка, несколько сиблингов (братьев/сестер), несколько супругов и несколько детей. Это всё, что должно быть у любого отдельного человека.
Имея это у каждого, в любой момент вы можете выстроить дерево как в прошлое, так и в будущее. Но корнем всегда должен быть конкретный человек.
Не должно быть узла «брак». Это не сущность. Соответственно, не может быть такого узла. Узлы - это люди.
Поскольку в этой структуре есть поколения, то все супруги - это одно поколение. У основного человека две связи наверх - родители; какое-то количество связей вбок - супруги и сиблинги; какое-то вниз - потомки.
Заметьте, для основного человека нет никакой разницы, от какого супруга или постороннего человека у него потомки. Это не его атрибут, это атрибут потомка. Если надо, его можно получить оттуда.
Egor2119, чтобы не изобретать велосипед, сделайте БД SQLite in-memory, зато всё будет стандартно и любому понятно.
Кажущаяся сложность на начальном этапе в дальнейшем может оказаться облегчением, т.к. у БД стандартный интерфейс и всегда можно её заменить на более взрослую.
Впрочем, и обычный словарь для начала вполне пойдёт.
alekseiami, Конечно, будет сложно поддерживать консистентность базы, будут проблемы со сквозным индексом и т.п., но раз уж условие стоять на одной ноге, а второй чесать за ухом, то уж чего теперь…
alekseiami, может, побить базу на куски? В SQLite нет партишинга, но можно же извратиться и насоздавать баз под каждый чих и базу, в которой ссылаться на нужную базу…
Каждая функция должна делать только одно.
В идеале еще к каждой функции написать несколько тестов.