feat: delete ps node #20
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Vorkout/connect#20
Reference in New Issue
Block a user
No description provided.
Delete Branch "VORKOUT-29"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@@ -89,0 +120,4 @@return all_child_nodesasync def get_nodes_for_deletion_ordered(connection: AsyncConnection, node_id: int) -> List[int]:Там FK у node_link на node_id (т.е. нужно удалять node_link раньше node_id, но позже next_node_id), есть у меня сомнение, что такое упорядочивание здесь реализовано.
Тут можно было после размышлений поступить проще - удалять Узлы прямым запросом через алхимию с JOIN'ами по связям, тогда можно не париться с упорядочиванием.
Второй вариант - сделать ON DELETE CASCADE в определении FK на node_link'е.
Ещё момент. Циклы у нас могут быть, когда замыкающая цикл нода ссылается куда-то "наверх".
Это решается маркировкой уровня "иерархии" у нод и последующей проверкой перехода по уровням (вниз - норм, а если вверх - не трогаем ноду, на которую ссылаются), пока можно не реализовывать, т.к. до циклов надо реально ещё дожить, но момент нужно держать в уме.
@@ -89,0 +105,4 @@query = (select(ps_node_table).join(node_link_table, ps_node_table.c.id == node_link_table.c.next_node_id).where(node_link_table.c.node_id == current_node_id)У меня вопрос - а насколько много запросов тут может проходить?
Это я отсылаю к проблеме N + 1.
Особой нагрузки тут не предвидится, как минимум в разрезе редактирования тела схемы процесса. Речь про максимум пару десятков узлов, в исключительных случаях может быть побольше.
Даже если речь идёт о паре десятков узлов, то это уже получается 20 похожих запросов подряд.
С этим трудно спорить.
В целом, если учитывать латентность сетевую и парсинг SQL, оно уложится в 0.1-0.3сек на подобных данных.
Но согласен, что это антипаттерн с т.з. работы с БД.
@@ -89,0 +183,4 @@successfully_deleted = []for node_id in node_ids:success, error_message = await delete_ps_node_by_id_completely(connection, node_id)Ну и здесь на каждый id будет по несколько отдельных запросов. Неэффективно.
@@ -32,0 +54,4 @@)try:await db_user_role_validation_for_list_events_and_process_schema_by_list_event_id(Что за любовь к длиннейшим названиям?)
Это LLM, мне кажется )
В каком то из прошлых ПРов раз было замечание о неинформативности названий функций, мне переименовать?
Это предмет крупного рефакторинга. В основном наблюдение говорит об избыточности семантики в названиях функций, т.к. при корректном подходе к проектированию (инкапсюляция) нет необходимости повторять в методе контекстную часть как минимум (т.е. если метод сидит в классе ps_node, то повторять это в названии скорее тавтология).
Парадигма ООП и частично ФП за сохранение читаемости в условиях умолчаний.
В большинстве случаев для соблюдения уникальности семантики названия метода и переменной должно хватать схемы Императив + Объект (save_file), Предикат + Императив (can_edit, is_valid()), в исключительных случаях (если это общая библиотека функций и ресурсов) можно использовать Функция/Объект верхнего уровня + Императив + Целевой Объект.
Всё - три слова и контекст должны составлять уникальную семантику. Если не получается - значит есть проблемы в композиции и стоит сначала решить их.
Понял
Согласен. Семантика в названиях должна быть отображена, но это не значит, что для её выражения требуется по 10 слов, лишь главная суть для текущего контекста.
@@ -0,0 +49,4 @@def create_validation_error(message: str, status_code: int = 400, details: Optional[Dict[str, Any]] = Nonestatus_code: int = 422?Как будто бы в эндпоинтах не должно быть так много кода. Что скажешь, если повыносить бизнес-логику в сервисы?
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.