QUIK (версия 7.0.1.5)

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: Пред. 1 2 3 4 5 След.
RSS
QUIK (версия 7.0.1.5), function OnTrade(trade), трехкратный вызов на одно событие.
 
#51
13.11.2015 11:02:02
Мне приходится задавать одни и те же вопросы, потому что вы "виляете".
Вероятно, это вам необходимо
Цитата
Sergey Gorokhov пишет:
самостоятельно прочитать тему с начала
в т.ч. и свои посты.

Итак, вы можете обосновать своё утверждение?
Цитата
Sergey Gorokhov пишет:
я не вижу в trans_id=0 двусмысленного толкования.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#52
13.11.2015 11:23:56
И да, вопрос
Цитата
Старатель пишет:
OnTrade всегда приходит с заполненным полем trans_id?
Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную? Или нужно подождать второго-третьего колбека, чтобы убедиться в этом?
я вам повторил не для того, чтобы получить ответ на него от вас (ибо на это надежды мало). Ответ уже был дан в сообщении #34 (прочитайте его). А для того, чтобы вы наконец задумались над тем, что пишите.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#53
13.11.2015 18:43:23
В Система QUIK, 7.0 еще 19.10.2015
Цитата
Вячеслав писал:
OnTrade() на одну сделку теперь дает ТРИ обратных вызова?
И вопрос как-то остался без ответа ((
Тема  "trans_id=0" как бы опять не увела в сторону решение основной, на мой взгляд, темы, озвученной в вышеприведенной цитате.
:what:
Lbot3D
 
 
#54
13.11.2015 20:28:39
Цитата
_sk_ пишет:
Цитата
Чисто технически, да могут поменяться Чисто практически, такая ситуация маловероятна
Это плохо, если разработчики говорят в терминах вероятностей о поведении программы.

Представим, что пришла информация о сделке, где комиссии указаны нулевые. Это может произойти, если сделки по фьючерсу идут внутри дня. Адекватная торговая программа пишет в какой-нибудь лог информацию о сделке с нулевой комиссией, а потом ВНЕЗАПНО обнаруживается, после прихода ещё одного коллбэка, что комиссии-то ненулевые!
И что, такое реально может быть? А как же оно до 7-й версии работало?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#55
14.11.2015 09:25:05
В шестой версии такого не бывает, т.к. она не поддерживает обновление строк в таблице сделок. Про это Горохов писал.

В седьмой версии, как мне кажется, такого быть также не должно, но спецификация, которую разработчики quik предлагают нам (любые поля могут обновляться сколько угодно раз) приводит к тому, что невозможно разрабатывать по ней скрипты, хоть и удобно для ARQA с точки зрения минимизации своей ответственности. Примеры Вы (реальный) и я (гипотетический, но по спецификации) привели.

Гарантий нет, всё делаем на свой страх и риск. Занимаемся эмпирическим программированием. Конечно, такое отношение к пользователям не радует. А то, что пишет Горохов - отдельная беда, хотя может у него задача такая - держать первую линию обороны от недовольных пользователей.
 
 
#56
14.11.2015 09:32:37
Цитата
_sk_ пишет:
В шестой версии такого не бывает, т.к. она не поддерживает обновление строк в таблице сделок.
Я потому и задаюсь вопросом: в 6-й версии таблица сделок была не обновляемой. Это значит, что пришедшая с биржи информация по сделке была либо сразу полной, либо...
Почему теперь концепция изменилась, и биржевые параметры в таблице сделок могут обновляться бесконечное число раз?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#57
14.11.2015 14:03:59
Хочу добавить свою ложку в Вашу бочку.
Возможно мирное решение данной проблемы заключается в следующем.
-------------------
Создателям скриптов (т е нам, вам) взять за основу тот факт, что скрипты
работают с асинхронными событиями.
---------------------
Следовательно, пока событие не наступило,
его нет,
и гадать о его наступлении бессмысленно.
------------------------------
Например,
если trans_id=0 , то это означает, что "ноль"
если trans_id=nil , то это означает, что "nil"
А когда  поступит  trans_id не равен 0, то и будем его обрабатывать.
Т е либо мы обрабатываем интересующие нас события, либо игнорируем их.
------------------------------
При этом, безусловно,
список событий должен быть отражен в документации разработчиков.
----------------------------
Тогда нет проблемы в том,
что и сколько  раз обновляется.
 
 
#58
14.11.2015 14:33:19
Цитата
Старатель пишет:
Цитата
_sk_ пишет:
В шестой версии такого не бывает, т.к. она не поддерживает обновление строк в таблице сделок.
Я потому и задаюсь вопросом: в 6-й версии таблица сделок была не обновляемой. Это значит, что пришедшая с биржи информация по сделке была либо сразу полной, либо...
Почему теперь концепция изменилась, и биржевые параметры в таблице сделок могут обновляться бесконечное число раз?
Они сделали это по своим внутренним причинам.  :lol:  
Цитата
Николай Камынин пишет:
если trans_id=0 , то это означает, что "ноль"
если trans_id=nil , то это означает, что "nil"
А когдапоступитtrans_id не равен 0, то и будем его обрабатывать.
Т е либо мы обрабатываем интересующие нас события, либо игнорируем их.
В том случае, которое было упомянуто в самом начале этой темы, приходили три отклика OnTrade() с одинаковым количеством параметров и одинаковыми данными.
И все, что было в моем скрипте ориентировано на обработку OnTrade() летит в тар-тарары.
Фактически, эта функция была выведена из строя.
И если с несколькими откликами OnOrder() мы уже сжились, но засады по OnTrade() мало кто ожидал.
И тема trans_id, вобще-то, не при чем.
То, что она появилась и что с ней происходит, это интересно, но не в этой теме.
Lbot3D
 
 
#59
14.11.2015 15:19:37
Цитата
Старатель пишет:
Почему теперь концепция изменилась, и биржевые параметры в таблице сделок могут обновляться бесконечное число раз?
На бирже концепция не менялась
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Какие параметры являются обновляемыми?
Все параметры которых нет на бирже, плюс те параметры которые на бирже можно менять, являются обновляемыми.
Речь не только про TRANS_ID (это только частный случай) , есть еще комиссия брокера, флаги, UID и д
 
 
#60
14.11.2015 17:56:47
Согласен с тем, что мирное решение проблемы состоит в нормальной документации того, что и как может меняться в списке параметров. ARQA пока не хочет это делать, чтобы не быть связанной какими-либо обязательствами, перебрасывая проблемы на пользователей.

У себя в коде я сделал так: если приходит OnTrade, в котором нет всех параметров, необходимых для обработки события, игнорируем это событие и надеемся, что придёт ещё одно. Обрабатываем заполненное событие как и раньше (молясь о том, что все необходимые параметры заполнены окончательными значениями; список приведён мною раньше; от ARQA достаточно подтверждения, что эти параметры заполняются синхроно и окончательно). Значения uid, trans_id ищу сам, хотя сейчас будет помощь от Quik, но код переписывать уже не хочется (новички, кто ещё не писал исполнителя заявок, правда, это может и оценят). При этом запоминаю ключи class_code.order_num для фильтрации повторных уже не нужных OnTrade.

По моим оценкам задержка при получении повторных коллбэков с trans_id примерно те же, что и при получении OnOrder с этой информацией. Т.е. быстрее реально не стало. Из-за повторов событий о сделках код даже стал медленнее, т.к. приходится делать дополнительные проверки и фильтрацию.
 
 
#61
14.11.2015 18:32:24
Скрытый текст

Цитата
Sergey Gorokhov пишет:
На бирже концепция не менялась
Так я и не говорил, что на бирже концепция поменялась.
Я спрашиваю почему, если это ваша инициатива, то биржевые параметры стали обновляемыми (про trans_id и uid я не спрашиваю), есть ли объективное объяснение, почему они могут бесконечно обновляться?
И почему, если эти параметры обновляемы внутри вашей системы (ведь так?), то вы не желаете приводить их полный список, а отсылаете к описанию биржевого интерфейса угадывать, какие из параметров вы могли сделать обновляемыми?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#62
15.11.2015 08:00:25
Цитата
Старатель пишет:
биржевые параметры стали обновляемыми
"биржевые" параметры, НЕ стали вдуг обновляемыми, кто Вам такое сказал? Еще раз внимательно прочитайте мой ответ.
 
 
#63
15.11.2015 09:45:08
Вот, насобирал: 1.
Цитата
Sergey Gorokhov пишет:
На сделке, которая является сущностью торговой системы нет некоторых полей, которые есть в QUIK
В частности это UID, TRANS_ID а также набор флагов и ряд других специфичных параметров
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
Иначе, отправка сделки задерживалась бы до установки всех параметров, что гораздо хуже чем получить подряд несколько обновлений.
2.
Цитата
Sergey Gorokhov пишет:
Как уже было сказано и еще раз повторю, трансляция нескольких OnTrade есть, будет и от этого избавляться не планируется, по уже озвученным причинам.
Это значит что если данная реализация приводит к неудобству, предложите способ его избежать и мы зарегистрируем пожелание. Варианты типа "сделайте как было" не принимаются.
3.
Цитата
Sergey Gorokhov пишет:
Серьезно, обновляются те поля которые пока еще не доступны в LUA
4.
Цитата
Sergey Gorokhov пишет:
"биржевые" параметры, НЕ стали вдуг обновляемыми, кто Вам такое сказал? Еще раз внимательно прочитайте мой ответ.
Если продолжить цепляться к словам, то, в общем, не важно, что именно "биржевые" параметры" не стали обновляемыми.
Стали обновляемыми сделки, при этом, очень странным образом, обновляемые сделки вовсе не обновляются, а просто повторяются три раза.
Да, прочитал: "обновляются те поля которые пока еще не доступны в LUA". А зачем их отправлять в Lua, в таком случае?
Если они не важны для нее, не отправляйте их в "втемную", тупо присоединив их к тем данным, которые уже отправлялись ранее!

Кстати, http://www.lua.org/about.html:
Цитата
"Lua" (pronounced LOO-ah) means "Moon" in Portuguese. As such, it is neither an acronym nor an abbreviation, but a noun. More specifically, "Lua" is a name, the name of the Earth's moon and the name of the language. Like most names, it should be written in lower case with an initial capital, that is, "Lua". Please do not write it as "LUA", which is both ugly and confusing, because then it becomes an acronym with different meanings for different people. So, please, write "Lua" right!
Lbot3D
 
 
#64
15.11.2015 10:13:10
Цитата
Sergey Gorokhov пишет:
"биржевые" параметры, НЕ стали вдуг обновляемыми, кто Вам такое сказал?
Это ваши слова?
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Поэтому обозначить, какие именно параметры являются не обновляемыми для вас не составит труда.
Обновляемые параметры мы уж определим сами методом исключения.
Вы можете самостоятельно определить список, просто взглянув на описание биржевого интерфейса.
Тогда не нужно перекладывать ответственность на биржу.

И, коль вы не отвечаете на вопросы, я вынужден их повторить:
Цитата
Старатель пишет:
Я спрашиваю почему, если это ваша инициатива, то биржевые параметры стали обновляемыми (про trans_id и uid я не спрашиваю), есть ли объективное объяснение, почему они могут бесконечно обновляться?
И почему, если эти параметры обновляемы внутри вашей системы (ведь так?), то вы не желаете приводить их полный список, а отсылаете к описанию биржевого интерфейса угадывать, какие из параметров вы могли сделать обновляемыми?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#65
15.11.2015 11:25:44
Чем больше "недоказанностей", тем больше возникает вопросов:
Можно ли рассчитывать, что для сделки, которая была 2 часа назад, сохранённые сейчас параметры останутся неизменными через час?
Может ли брокер повлиять на изменение параметров сделки, которая уже была получена клиентом?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#66
15.11.2015 14:48:00
Цитата
Старатель пишет:
Тогда не нужно перекладывать ответственность на биржу.
Еще раз вынужден обратить внимание что Вы неверно интерпретируете сказанное.
Был вопрос
Цитата
Старатель пишет:
Какие параметры являются обновляемыми?
На что был ответ
Цитата
Sergey Gorokhov пишет:
Все параметры которых нет на бирже, плюс те параметры которые на бирже можно менять, являются обновляемыми.

Вы же сделали абсолютно неверный вывод:
Цитата
Старатель пишет:
биржевые параметры стали обновляемыми

Есть другие биржи (не МБ) и на них некоторые параметры сделки обновляемые. Например там сделки можно отменять.
Мы поддержали этот функционал в QUIK
На МБ ничего не менялось, там параметры обновляемыми НЕ стали.


Цитата
Старатель пишет:
Может ли брокер повлиять на изменение параметров сделки, которая уже была получена клиентом?

Нет не может.
 
 
#67
15.11.2015 14:53:41
Цитата
XXM пишет:
А зачем их отправлять в Lua, в таком случае?
Терминал никогда не будет фильтровать колбэки, кому их слать, а кому нет.
Пришел колбэк получите. Фильтра не будет.
И это абсолютно правильный и логичный подход к реализации.
 
 
#68
15.11.2015 15:00:33
Цитата
Старатель пишет:
Можно ли рассчитывать, что для сделки, которая была 2 часа назад, сохранённые сейчас параметры останутся неизменными через час?
В общем случае нет. В частном из-за сбоя не сервере.
 
 
#69
15.11.2015 15:05:09
Цитата
Старатель пишет:
Чем больше "недоказанностей", тем больше возникает вопросов:
А вопросы возникают не из-за "недоказанностей"
На последние вопросы от Вас, я просто повторил ответы которые уже давались именно в этой ветке форума
 
 
#70
15.11.2015 15:56:45
Я делаю выводы на основе ваших слов:
Скрытый текст

Цитата
Sergey Gorokhov пишет:
Есть другие биржи (не МБ) и на них некоторые параметры сделки обновляемые. Например там сделки можно отменять.
Мы поддержали этот функционал в QUIK
На МБ ничего не менялось, там параметры обновляемыми НЕ стали.
Так всё-таки "биржевые" параметры сделки стали обновляемы, но не для МБ? Или я опять делаю неверный вывод?

Цитата
_sk_ пишет:
Осталось надеяться, что если мы в очередной коллбэк OnTrade увидели установленные поля
class_code, sec_code, price, qty (или как он там теперь будет называться), order_num (или как он там теперь будет называться), trade_num, clearing_comission, exchange_comission, tech_center_comission, datetime, settle_date,
то при последующих коллбэках эти поля уже не поменяют свои значения.

Или могут и поменять?
Цитата
Sergey Gorokhov пишет:
Чисто технически, да могут поменяться
Чисто практически, такая ситуация маловероятна
Обратите внимание на выделенные жирным шрифтом параметры. Вы не опровергли, что значения этих параметров могут поменяться.
Ну и что нам с этой информацией делать? Сидеть "на измене" и ждать "засады"?
Давайте жёстко разграничим: в штатной ситуации так-то и так-то; если произошло то-то - то это не штатная ситуация и надо бить тревогу.
А то тут действительно начинаешь путаться.

Цитата
Sergey Gorokhov пишет:
На последние вопросы от Вас, я просто повторил ответы которые уже давались именно в этой ветке форума
Ой ли?
Цитата
Sergey Gorokhov пишет:
Не совсем так, в штатной ситуации да действительно, если trans_id есть то поменяться он уже не может.
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Это справедливо для всех параметров?
нет не для всех, а только для тех которые берутся из транзакции, конкретно UID и trans_id
Конкретно на этот вопрос вы не отвечали. Да и сейчас ваш ответ не ясен (здесь интересуют все обновляемые параметры):
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Можно ли рассчитывать, что для сделки, которая была 2 часа назад, сохранённые сейчас параметры останутся неизменными через час?
В общем случае нет. В частном из-за сбоя не сервере.
"Нет" - означает "нет, нельзя рассчитывать"? Или что "параметры сделки останутся неизменными"?


И для понимания работы данного функционала и решения проблемы с двусмысленностью чтения некоторых значений параметров необходимо:
1) Дать исчерпывающий список обновляемых параметров.
2) Внести изменения в ПО таким образом, чтобы все отсутствующие параметры имели значение nil (это касается не только OnTrade).
3) Для параметра trans_id внести изменения таким образом, чтобы для транзакций, заявок, сделок без "Идентификатора транзакции" значением по-умолчанию был 0. Если значение параметра ещё не определено, то соответственно - nil.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#71
15.11.2015 17:54:14
Цитата
Старатель пишет:
Так всё-таки "биржевые" параметры сделки стали обновляемы, но не для МБ? Или я опять делаю неверный вывод?
Нет не стали, а были и уже давно. И речь не про МБ.
Цитата
Старатель пишет:
Ой ли?
О том и речь, что на один и тот же вопрос было уже три ответа.
Цитата
Старатель пишет:
" Нет " - означает "нет, нельзя рассчитывать "? Или что "параметры сделки останутся неизменными "?
Это уже четвертый раз когда Вы задаете все тот же вопрос, на который все тот же ответ.
Еще раз повторяю:
Цитата
в случае сбоя на стороне сервера, есть вероятность что сделка может приехать без UID и без trans_id
Цитата
Старатель пишет:
1) Дать исчерпывающий список обновляемых параметров.
нет.
Цитата
Старатель пишет:
2) Внести изменения в ПО таким образом, чтобы все отсутствующие параметры имели значение nil (это касается не только OnTrade).
Вы опять повторяетесь, на это уже был ответ.
Цитата
Пожелание зарегистрировали.
Цитата
Старатель пишет:
3) Для параметра trans_id внести изменения таким образом, чтобы для транзакций, заявок, сделок без "Идентификатора транзакции" значением по-умолчанию был 0 . Если значение параметра ещё не определено, то соответственно - nil .
И снова Вы повторяетесь, на это уже был ответ

Цитата

Вы же предлагаете чтобы сервер делал одну и ту же работу два раза.
первый раз он будет искать транзакцию по сделке чтобы проставить trans_id=0
а второй раз чтобы проставить правильный trans_id
масло масленое получается.
 
 
#72
15.11.2015 17:56:56
Старатель,

Еще раз просьба, внимательно прочитать тему с самого начала
Вы задаете одни и те же вопросы, на которые будут одни и те же ответы.
 
 
#73
15.11.2015 19:07:00
Цитата
Sergey Gorokhov пишет:
Вы же предлагаете чтобы сервер делал одну и ту же работу два раза.
первый раз он будет искать транзакцию по сделке чтобы проставить trans_id=0
а второй раз чтобы проставить правильный trans_id
Я этого не предлагал.
Скрытый текст


Учитывая неосведомлённость сотрудников технической поддержки об изменениях в новой версии QUIK v.7, можно сделать вывод, что ваше нежелание привести нормальное описание работы нового функционала связано с некомпетентностью в данном вопросе.

Поэтому я вынужден привлечь внимание начальства к тому, как работает служба технической поддержки ARQA Technologies:
проведите переаттестацию ваших сотрудников и наладьте взаимоотношение между отделами, в частности между техподдержкой и программистами: это недопустимо, когда специалист технической поддержки не знает продукт, поддержкой которого занимается. И я сейчас говорю не конкретно об этой теме: могу привести с десяток примеров, где мне и другим пользователям приходится поправлять сотрудников техподдержки, дабы они не вводили в заблуждение своими неверными высказываниями относительно работы программы.

И пригласите, пожалуйста, более компетентного сотрудника, чтобы закрыть вопрос.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#74
16.11.2015 07:28:18
Еще раз, более подробно
[QUOTE][USER=54]Старатель[/USER] пишет:
При отправке колбеков с сервера на терминал trans_id=0 можно использовать для обозначения, что данный параметр проставлен. Если параметр не проставлен, то он = nil .
[/QUOTE]

Как это будет работать по Вашему предложению:
Допустим отправили транзакцию через LUA

На сервер приехала сделка. trans_id не биржевой параметр, а значит сделка приезжает без него.
Как следствие, сервер не знает заявка которая привела к сделке выставлена через интерфейс или через Lua. Поэтому он не может сразу определить что послать клиенту trans_id=0 или trans_id=nil или trans_id=число

Согласно Вашей логике, сервер должен как то узнать что сделка была выставлена через Lua и отправить клиенту trans_id=0
Чтобы это сделать, сервер ищет транзакцию которая привела к выставлению заявки.
Допустим он ее нашел и выяснил, что на транзакции есть trans_id, а значит согласно Вашей логике он должен отправить trans_id=0
А потом он еще раз должен отправить уже trans_id=число.
То есть серверу придется два раза отправить клиенту сделку

Сейчас работает так:
Приехала сделка.
Сервер ищет транзакцию
Он ее нашел и выяснил что на транзакции есть trans_id и отправляет сделку клиенту с проставленным trans_id.
Если на транзакции нет trans_id он отправляет "0"
 
 
#75
16.11.2015 09:43:21
Цитата
Sergey Gorokhov пишет:
Допустим он ее нашел и выяснил, что на транзакции есть trans_id, а значит согласно Вашей логике он должен отправить trans_id=0
Ну что вы лепите? Что вы вырываете куски из текста?
Цитата
Старатель пишет:
Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id, если его не было, со значением "по-умолчанию" = 0.
Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра.

А когда транзакция найдётся, то проставить найденное значение параметра. И там будет либо номер транзакции либо честный ноль.
Согласно моей логике, серверу вообще не надо знать, что транзакция подана именно через Lua. (Не надо придумывать отсебятины.)
Согласно моей логике сервер должен сохранить транзакцию в своей SQL-базе с номером транзакции, если он был указан, либо с нулём, если он не был указан.
При обратной отправке колбека клиенту, соответственно и отправлять этот номер. Один раз. Зачем два раза-то?
(Это поэтому у вас сейчас 3 колбека? Даже если допустить, что в первом всегда приходят не все параметры, почему все недостающие нельзя отправить в одном следующем колбеке?)

Складывается впечатление, что вы узнаёте о новом функционале, по мере того, как поступают вам вопросы на эту тему.
Более компетентный сотрудник есть?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#76
16.11.2015 09:57:41
Цитата
Sergey Gorokhov пишет:
На сделке, которая является сущностью торговой системы нет некоторых полей, которые есть в QUIK
В частности это UID, TRANS_ID а также набор флагов и ряд других специфичных параметров
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
Цитата
Sergey Gorokhov пишет:
Сейчас работает так:
Приехала сделка.
Сервер ищет транзакцию
Он ее нашел и выяснил что на транзакции есть trans_id и отправляет сделку клиенту с проставленным trans_id.
Если на транзакции нет trans_id он отправляет "0"
Вы даёте крайне противоречивую информацию в своих сообщениях: во втором случае, вы не указываете, что trans_id может отправляться несколько раз.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#77
16.11.2015 10:07:52
Цитата
Старатель пишет:
Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id, если его не было, со значением "по-умолчанию" = 0.
Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра.
Сейчас оно так и работает.
Цитата
Старатель пишет:
Вы даёте крайне противоречивую информацию в своих сообщениях: во втором случае, вы не указываете, что trans_id может отправляться несколько раз.
Вы путаете общий случай и частный.
 
 
#78
16.11.2015 10:09:15
Цитата
Старатель пишет:
без проставленного параметра
только вместо проставленного параметра nil
 
 
#79
16.11.2015 10:09:23
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
без проставленного параметра
только вместо проставленного параметра nil
то есть 0
 
 
#80
16.11.2015 10:24:38
Давайте еще раз с Ваших слов

Цитата
Старатель пишет:
Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id , если его не было, со значением "по-умолчанию" = 0 .
Сейчас ровно так и работает
Цитата
Старатель пишет:
Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра .
Это частный случай, который в общем маловероятен (проверьте сами) из-за которого в этой ветке весь сыр бор.
Допустим, как уже было сказано приехала сделка. И мы знаем что эта сделка была выставлена через интерфейс
С Ваших слов сервер отправил ее клиенту с trans_id=nil
Далее, поиск по базе, он нашел транзакцию и еще раз отправил trans_id=0
Итого, опять будет лишняя отправка.


Вот это
Цитата
Старатель пишет:
При отправке колбеков с сервера на терминал trans_id=0 можно использовать для обозначения, что данный параметр проставлен. Если параметр не проставлен, то он = nil .

Противоречит Вот этому
Цитата
Старатель пишет:
Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id , если его не было, со значением "по-умолчанию" = 0 .
 
 
#81
16.11.2015 11:05:56
Цитата
Sergey Gorokhov пишет:
Вот это
Цитата
Старатель пишет:
При отправке колбеков с сервера на терминал trans_id=0 можно использовать для обозначения, что данный параметр проставлен. Если параметр не проставлен, то он = nil .
Противоречит Вот этому
Цитата
Старатель пишет:
Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id , если его не было, со значением "по-умолчанию" = 0 .
Специально для вас выделил жирным. Или надо цветом и подчеркнуть?

Цитата
Sergey Gorokhov пишет:
Допустим, как уже было сказано приехала сделка. И мы знаем что эта сделка была выставлена через интерфейс
С Ваших слов сервер отправил ее клиенту с trans_id=nil
С моих слов, если вы уже знаете, что сделка была выставлена через интерфейс, то и отправляйте 0.
По-моему я достаточно ясно описал своё предложение (и не надо выдирать слова из контекста):
Цитата
Старатель пишет:
Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра.
А когда транзакция найдётся, то проставить найденное значение параметра. И там будет либо номер транзакции либо честный ноль.
Я уже не знаю, как вам ещё объяснить. Я искренне надеюсь, что лично вы не принимаете никакого участия в разработке продуктов ARQA.

Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра .
Это частный случай, который в общем маловероятен (проверьте сами) из-за которого в этой ветке весь сыр бор.
Вам уже говорили:
Цитата
_sk_ пишет:
Это плохо, если разработчики говорят в терминах вероятностей о поведении программы.
И вы сами объясняете наличие нескольких колбеков необходимостью отправки дополнительных параметров, в частности uid и trans_id:
Цитата
Sergey Gorokhov пишет:
На сделке, которая является сущностью торговой системы нет некоторых полей, которые есть в QUIK
В частности это UID, TRANS_ID а также набор флагов и ряд других специфичных параметров
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
Цитата
Sergey Gorokhov пишет:
Цитата
Антон пишет:
Почему не оставили только для заявок, меньше нужно было бы информации повторной пересылать.
Потому что пользователи хотели чтобы на сделках был TRANS_ID и другие параметры
Я вам задавал прямой вопрос:
Цитата
Старатель пишет:

OnTrade всегда приходит с заполненным полем trans_id?
Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную?
Вы можете на него также прямо без ёрзаний ответить? (Сейчас говорю только про штатную ситуацию.)
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#82
16.11.2015 11:42:38
Цитата
Старатель пишет:
OnTrade всегда приходит с заполненным полем trans_id?
Нет не всегда, в частности из-за сбоя на сервере может приехать 0, а потом правильный trans_id или он может вообще не приехать.
Цитата
Старатель пишет:
Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную?
В общем случае да, в частном см. выше.

Цитата
Старатель пишет:
Цитата Старатель пишет:
Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра .
А когда транзакция найдётся, то проставить найденное значение параметра . И там будет либо номер транзакции либо честный ноль .
В случае когда транзакция была отправлена через терминал, в частном случае это означает что сервер будет отправлять лишний колбэк.
 
 
#83
16.11.2015 11:51:16
Старатель,

Мы можем зарегистрировать пожелание "отличать сделки порожденные транзакцией выставленной через интерфейс от выставленной через Lua" без конкретики озвученной в Вашем предложении.
Устроит такой вариант закрытия темы?
 
 
#84
16.11.2015 12:07:11
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
OnTrade всегда приходит с заполненным полем trans_id?
Нет не всегда, в частности из-за сбоя на сервере может приехать 0, а потом правильный trans_id или он может вообще не приехать.
Цитата
Старатель пишет:
Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную?
В общем случае да, в частном см. выше.
Вы сейчас извиваетесь, как уж на сковородке.
Таким образом, теперь вы сами опровергаете свои же слова о повторной приходе колбека OnTrade необходимостью отправлять дополнительные параметры, в частности uid и trans_id?

Или (задам опять прямой вопрос, на который вы так не хотите давать прямого ответа, хотя вопрос выше был итак достаточно чётким):

Может ли в штатной ситуации trans_id прийти незаполненным (в текущей реализации это означает ноль) в первом колбеке?

На всякий случай, привожу ссылку на ответ более компетентного сотрудника, как это работает в 6-й версии: OnOrder без UID
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#85
16.11.2015 12:10:26
Цитата
Sergey Gorokhov пишет:
Мы можем зарегистрировать пожелание "отличать сделки порожденные транзакцией выставленной через интерфейс от выставленной через Lua" без конкретики озвученной в Вашем предложении.
Устроит такой вариант закрытия темы?
Как меня может устроить такой вариант, если в вашем предложении нет никакой конкретики?
И потом, почему обязательно Lua? Сервер знает, что транзакция подана через Lua, а не Api или QPILE?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#86
16.11.2015 12:19:55
Цитата
Старатель пишет:
Таким образом, теперь вы сами опровергаете свои же слова о повторной приходе колбека OnTrade необходимостью отправлять дополнительные параметры, в частности uid и trans_id ?
Не вижу противоречий, Вы спрашивали конкретно про trans_id, я Вам ответил конкретно про trans_id.
В посте на который Вы ссылались речь была не только про trans_id.
Цитата
Старатель пишет:
Может ли в штатной ситуации trans_id прийти незаполненным (в текущей реализации это означает ноль) в первом колбеке?
Конкретно про trans_id да может приехать 0, в случае когда заявка выставлялась через интерфейс.
Если говорить про случай когда заявка выставлялась через LUA, то в общем случае trans_id в штатной ситуации он приезжает заполненный.
Цитата
Старатель пишет:
На всякий случай, привожу ссылку на ответ более компетентного сотрудника, как это работает в 6-й версии: OnOrder без UID
Частный случай когда сделка приехала раньше ответа на транзакцию тоже возможен.
 
 
#87
16.11.2015 12:21:04
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Мы можем зарегистрировать пожелание "отличать сделки порожденные транзакцией выставленной через интерфейс от выставленной через Lua" без конкретики озвученной в Вашем предложении.
Устроит такой вариант закрытия темы?
Как меня может устроить такой вариант, если в вашем предложении нет никакой конкретики?
И потом, почему обязательно Lua? Сервер знает, что транзакция подана через Lua, а не Api или QPILE?
Речь действительно не только про Lua, просто так проще передать мысль
 
 
#88
16.11.2015 12:22:31
Цитата
Старатель пишет:
Как меня может устроить такой вариант, если в вашем предложении нет никакой конкретики?
Конкретно про это Вам был ответ по почте
 
 
#89
16.11.2015 12:33:50
Цитата
Sergey Gorokhov пишет:
Частный случай когда сделка приехала раньше ответа на транзакцию тоже возможен.
Мне не понятны ваши трактовки "частный"/"общий" случай.

Является ли следующая ситуация сбоем на сервере:
когда "сделка приехала раньше ответа на транзакцию" и в этом случае в первом колбеке trans_id=0 даже, если транзакция была подана не через интерфейс?


Я действительно уже многократно задаю один и тот же вопрос. Но я не получаю на него прямого ответа! Перестаньте уже вилять в конце концов.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#90
16.11.2015 13:18:01
Цитата
Старатель пишет:
Мне не понятны ваши трактовки "частный"/"общий" случай.
Давайте попробуем определиться:
"Общий случай" - обычная рабочая ситуация
"Частный случай" - ситуация с исключительными параметрами, которые редко (или крайне маловероятно) проявляются в обычной работе.
"Сбой сервера" - непредвиденный рестарт сервера, предварительно вызванный какими-либо проблемами. В зависимости от характера проблем последствия могут быть не предсказуемы.
Цитата
Старатель пишет:
Является ли следующая ситуация сбоем на сервере:
когда "сделка приехала раньше ответа на транзакцию" и в этом случае в первом колбеке trans_id=0 даже, если транзакция была подана не через интерфейс ?
Данная ситуация не является сбоем, это "частный случай"
Да, в этом случае первым приедет trans_id=0 даже, если транзакция была подана не через интерфейс.
Так как trans_id (и UID тоже) хранится на записи об ответе на транзакцию.
При получении ответа на транзакцию, сервер повторно отправит сделку с заполненным trans_id.
 
 
#91
16.11.2015 14:06:43
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Является ли следующая ситуация сбоем на сервере:
когда "сделка приехала раньше ответа на транзакцию" и в этом случае в первом колбеке trans_id=0 даже, если транзакция была подана не через интерфейс ?
Данная ситуация не является сбоем, это "частный случай"
Да, в этом случае первым приедет trans_id=0 даже, если транзакция была подана не через интерфейс.
Так какого вы мне тут расписываете на 3-х страницах?!

Я вам говорю, что получив колбек с trans_id=0 (сюда можно вписать название любого другого обновляемого параметра), я не могу быть уверенным, что значением этого параметра действительно является 0 (ноль).
И меня (думаю и других пользователей QUIK) не волнует, что эта ситуация маловероятна в условиях штатной работы сервера.

Получив trans_id=0 (сюда можно вписать название любого другого обновляемого параметра), я должен выполнить определённую задачу.
А что потом, когда эта "маловероятная" ситуация произойдёт, я буду просить биржу откатить сделки обратно, потому что Sergey Gorokhov сказал мне, что это "маловероятно"?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#92
16.11.2015 14:09:31
Цитата
Старатель пишет:
Так какого вы мне тут расписываете на 3-х страницах?!
Не понятно какой реакции Вы ожидаете.
 
 
#93
17.11.2015 01:05:33
По мне так все понятно излагает Старатель.
И так же понятно, что Сергей Горохов в данном случае на вопрос не отвечает.
Для убедительности теперь и мне, наверное, нужно цитат добавить пачку?
Сергей, бывает подклинивает всех. Я - не исключение, Вы - тоже.
Ваши коллеги решили Вас одного оставить разбираться с этой темой? Это повинность такая? Чтобы потом пользователи не стали сравнивать слова Вас и Вашего коллеги?
Проясните уже, наконец, про nil и 0. Хоть кто-нибудь. Можно инкогнито)
 
 
#94
17.11.2015 07:20:20
Цитата
Viktor MMM пишет:
По мне так все понятно излагает Старатель.
И так же понятно, что Сергей Горохов в данном случае на вопрос не отвечает.
Для убедительности теперь и мне, наверное, нужно цитат добавить пачку?
Сергей, бывает подклинивает всех. Я - не исключение, Вы - тоже.
Ваши коллеги решили Вас одного оставить разбираться с этой темой? Это повинность такая? Чтобы потом пользователи не стали сравнивать слова Вас и Вашего коллеги?

На все вопросы ответы уже были, на главный вопрос темы топика, а именно в каких случаях  trans_id может не доехать, ответ уже давался не однократно, а именно по моим скромным подсчетам уже раз пять.
Если есть что-то конкретное спрашивайте.

Цитата
Viktor MMM пишет:
Проясните уже, наконец, про nil и 0. Хоть кто-нибудь. Можно инкогнито)

Про nil, его нет и не было, мы зарегистрировали пожелание. Дословно оно звучит так "чтобы во всех колбеках возвращающих таблицы, при отсутствии значения параметра передавать nil вместо "0"

Про "0", конкретно в trans_id. Сейчас для trans_id значение "0" является значением "по умолчанию"
Это значит что если он не задан, приедет "0"
Если он задан, но по каким-то причинам не доехал, то с начала приедет "0" а потом правильное число.
Случаи когда он может не доехать озвучивались ранее.
1) сбой на сервере
2) когда сделка приехала раньше ответа на транзакцию.

Ув. Старатель, обращает внимание на то что в такой реализации, нет 100% уверенности что сделка приехавшая с trans_id=0 выставлена через интерфейс терминала, так как позже может приехать trans_id=число.
Да сейчас это действительно так и способ решить проблему уже озвучивался "используйте комментарий"
Далее, предлагается разделить понятия nil и 0, а именно в базе записывать "0" (как сейчас) а в описанных выше случаях, при приезде сделки отправлять клиенту nil и далее делать поиск правильного trans_id. На что не однократно прозвучал ответ, что в такой реализации для отправки trans_id=0 будет лишний колбэк, которого сейчас нет. А лишние колбэки, судя по этой ветке форума, никому не нравятся. Соответственно мы предлагаем зарегистрировать пожелание в общих терминах, без озвученной конкретики и подумать над альтернативным решением, каким именно пока не понятно.
 
 
#95
17.11.2015 08:35:38
Цитата
Про nil, его нет и не было, мы зарегистрировали пожелание. Дословно оно звучит так "чтобы во всех колбеках возвращающих таблицы, при отсутствии значения параметра передавать nil вместо "0"
Замечательно, главное, чтобы реализация была в версии 7.0.1.x или 7.0.2.x.
Цитата
На что не однократно прозвучал ответ, что в такой реализации для отправки trans_id=0 будет лишний колбэк, которого сейчас нет. А лишние колбэки, судя по этой ветке форума, никому не нравятся.
Лишний коллбэк с trans_id = 0 для (гарантировано) ручной сделки мы потерпим.
Цитата
Соответственно мы предлагаем зарегистрировать пожелание в общих терминах, без озвученной конкретики и подумать над альтернативным решением, каким именно пока не понятно.
Плохо понятно, что имеется в виду. Со стороны программиста хотелось бы:
1) nil в полях таблицы коллбэка, если сервер хочет сообщить нам некую информацию, но ещё не вся таблица коллбэка заполнена по каким-то причинам (нет информации; чтобы не ждать, пока сервер что-то найдёт у себя во внутренних структурах);
2) не получать повторный коллбэк, если для пользователя набор значений в полях таблицы не меняется.
 
 
#96
17.11.2015 09:19:54
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
 
 
#97
17.11.2015 10:10:26
Цитата
Sergey Gorokhov пишет:
Про nil, его нет и не было, мы зарегистрировали пожелание. Дословно оно звучит так "чтобы во всех колбеках возвращающих таблицы, при отсутствии значения параметра передавать nil вместо "0"
Я бы уточнил: как 0 (ноль), так и "" (пустая строка) - оба значения сейчас могут трактоваться двусмысленно.

Вот в случае этой реализации и может возникнуть дополнительный колбэк, в зависимости от текущей реализации.
Если сейчас после колбэка со значением <0 = null (параметра нет)> не отправляется повторный колбэк со значением <0 = 0 (параметр заполнен)>, то при реализации указанного выше предложения будет возникать дополнительный колбэк.



Цитата
Sergey Gorokhov пишет:
Да сейчас это действительно так и способ решить проблему уже озвучивался "используйте комментарий"
Уже писал, что часто - это не выход из положения:
Цитата
Sergey Gorokhov пишет:
У пользователя может быть куча других роботов, алго-приводов и пр., где параметры транзакций уже давно жёстко заданы производителем.

Цитата
Sergey Gorokhov пишет:
Далее, предлагается разделить понятия nil и 0, а именно в базе записывать "0" (как сейчас) а в описанных выше случаях, при приезде сделки отправлять клиенту nil и далее делать поиск правильного trans_id. На что не однократно прозвучал ответ, что в такой реализации для отправки trans_id=0 будет лишний колбэк, которого сейчас нет.
При реализации конкретно этого предложения никаких лишних колбэков возникать не будет. Выше уже показал, когда может возникнуть дополнительный колбэк.



Цитата
Sergey Gorokhov пишет:
А лишние колбэки, судя по этой ветке форума, никому не нравятся.
А какая нам теперь разница, сколько колбэков обрабатывать: 3 или 4 или сколько там будет?
Для нас важно чёткое понимание получили ли мы интересующие нас данные или ещё нет.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#98
17.11.2015 10:19:33
Старатель,

Не вижу смысла отвечать на пост, все уже 100 раз повторялось и обсуждалось.
 
 
#99
17.11.2015 21:25:36
Всегда когда вижу подобные ответы, хочется спросить, а где учат так отвечать? Ведь всегда одна и та же схема.
Сам бы так хотел научиться.
Тебе говорят - как так? Что за хрень? Скажи, как надо?
А в ответ - лада седан.

По-моему никто не против новых колбеков. Будь их хоть 100. Лишь бы вот тот самый сотый, последний, как-то обозначался и однозначно интерпретировался.  
Баклажан!
 
 
#100
17.11.2015 21:37:04
касательно сотни коллбеков...

ничто не мешает пользователям самим их создать. Главное уйти от повсеместно навязываемой дешёвой парадигмы: когда коолбеки исполняются в основном потоке терминала.
Специально для Вас, пользователи, разработчики выделили для Вас на каждый скрипт - отдельный поток. Осталось только грамотно этим воспользоваться...
Спору нет - это кардинально изменит архитектуру Ваших примитивных торговых ботов. НО! Потратив время на создание своего торгового qlua-движка - Вы потом с торицей всё себе вернёте. Можно будет сабклассить ботов, быстро удалять/добавлять бумаги на которых они имеют право торговать и т. д. и т. п.
 
 
Страницы: Пред. 1 2 3 4 5 След.
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2024,
ARQA Technologies
Наверх