Уникальный номер заявки

Страницы: 1
RSS
Уникальный номер заявки
 
Уникальность номеров заявок order_num поддерживается только внутри одного торгового дня. Также как и trade_num для сделок.
Получается при использовании этих параметров в качестве индекса может возникнуть ситуация, что записи имеющиеся совпадут по индексу с новыми заявками и сделками дня, что может привести к труднопредсказуемым последствиям.
Использовать trans_id  в качестве уникального индекса тоже ненадежный способ, т.к. логика его передачи в сообщениях нестабильна. Также например случаются существенные задержки с поступлением OnTransReply и тогда невозможно отменить заявку, т.к. для этого необходим order_num, которого у нас еще может не быть.
Кто как решает эту проблему?
 
Цитата
bespalex написал:
Уникальность номеров заявок order_num поддерживается только внутри одного торгового дня. Также как и trade_num для сделок.
Получается при использовании этих параметров в качестве индекса может возникнуть ситуация, что записи имеющиеся совпадут по индексу с новыми заявками и сделками дня, что может привести к труднопредсказуемым последствиям.
Использовать trans_id  в качестве уникального индекса тоже ненадежный способ, т.к. логика его передачи в сообщениях нестабильна. Также например случаются существенные задержки с поступлением OnTransReply и тогда невозможно отменить заявку, т.к. для этого необходим order_num, которого у нас еще может не быть.
Кто как решает эту проблему?
Внутри дня используем номе сделки
А между днями - дополнительно дату.
Устроит такое решение?
 
номер сделки и дата торгов
 
это конечно вариант, но мне он не нравится отсутствием изящества, громоздкостью что ли. Кроме того, как справедливо раньше вы подметили, при работе с питоном приходится экономить операции.
На эту проблему накладывается возможное отсутствие trans_id в сообщениях, который я поддерживаю уникальным на своей стороне. Городить два индекса совсем не хотелось.
И что делать, если order_num не приходит? Ждать? Сколько? получается заявка в неопределенном статусе может находиться неопределенное время.
 
Цитата
bespalex написал:
это конечно вариант, но мне он не нравится отсутствием изящества, громоздкостью что ли. Кроме того, как справедливо раньше вы подметили, при работе с питоном приходится экономить операции.
На эту проблему накладывается возможное отсутствие trans_id в сообщениях, который я поддерживаю уникальным на своей стороне. Городить два индекса совсем не хотелось.
И что делать, если order_num не приходит? Ждать? Сколько? получается заявка в неопределенном статусе может находиться неопределенное время.
Можете показать пример громоздкости или затрат на вычисления?
---------------------
Вся история предыдущих дней в худшем случае обрабатывается  один раз до начала торгов. в лучшем случае обрабатывается вчера.
 
Просто не нравится этот вариант, тк есть уникальный trans_id, зачем еще один индекс городить. Пока попробовал переделать все на обработку по trans_id, но остается открытым вопрос как быть если система не вернула order_num за разумное время. Пока что приходится такую заявку "забыть" и идти дальше.
Страницы: 1
Читают тему
Наверх