#276 closed задача (fixed)
Критерии поиска конференций в CDR
| Reported by: | alx | Owned by: | dimag |
|---|---|---|---|
| Priority: | major | Milestone: | 2 очередь |
| Component: | ПО MC04-Dispatcher. Пульт диспетчера/техника | Keywords: | database |
| Cc: |
Description
Сейчас при фильтрации конференций по времени в качестве времени начала конференции используется время ее создания.
Возможно, это не совсем правильно, ибо конференция может быть создана по фактц прихода диспетчера на работу и его входа в систему, после чего в конференции часами ничего не происходит. Предлагается подумать, не будет ли разумнее и правильнее использовать при поиске в качестве времени начала конференции не время ее создания, а время начала записи (то есть момент подключения второго участника).
Change History (27)
comment:1 by , 8 years ago
follow-up: 4 comment:2 by , 8 years ago
Согласен что разумно использовать в качестве времени начала конференции в поиске время начала записи.
Алексей, каким образом это реализовать?
Добавим ещё один столбец в sql таблицу, в котором будет отмечатся время начала записи?
follow-up: 5 comment:3 by , 8 years ago
Я могу анализировать CDR файлы и просто отбрасывать неподходящие записи.
Конечно это не так быстро как SQL запрос, но при числе записей до 200-300 это не будет заметно.
Нужно проанализировать поля join_time и leave_time.
<cdr>
<conference>
...
<members>
<member type="recording_node">
<join_time type="UNIX-epoch">1470301070</join_time>
<leave_time type="UNIX-epoch">1470301085</leave_time>
comment:4 by , 8 years ago
Replying to san:
Согласен что разумно использовать в качестве времени начала конференции в поиске время начала записи.
Алексей, каким образом это реализовать?
Добавим ещё один столбец в sql таблицу, в котором будет отмечатся время начала записи?
Именно так.
comment:5 by , 8 years ago
Replying to dimag:
Конечно это не так быстро как SQL запрос, но при числе записей до 200-300 это не будет заметно.
А при числе 200-300 тысяч - будет...
Я думаю, не надо извращений, если уж делать - то делать хорошо и правильно.
follow-up: 7 comment:6 by , 8 years ago
| Keywords: | audio added |
|---|
Где этот столбец в таблице, пока нет никаких изменений.
follow-up: 9 comment:7 by , 8 years ago
Replying to dimag:
Где этот столбец в таблице, пока нет никаких изменений.
Пока нет, я жду решения от Александра. Если он скажет, что согласен, и начинаем действовать - я добавлю столбец в таблицу.
И зачем тут ключевое слово "audio"? :) По-моему эта задача со звуком никак не связана... :)
comment:9 by , 8 years ago
Replying to alx:
Где этот столбец в таблице, пока нет никаких изменений.
Пока нет, я жду решения от Александра. Если он скажет, что согласен, и начинаем действовать - я добавлю столбец в таблицу.
Согласен)
follow-up: 17 comment:10 by , 8 years ago
Дима, а ты не забудь что пргорамма должна успешно искать записи в базе с новым столбцом и без него (для совместимости со старой базой)
comment:12 by , 8 years ago
Можно так сделать. Тогда для старой версии БД, я буду использовать текущий алгоритм, для новой версии буду использовать новые колонки.
comment:13 by , 8 years ago
| Owner: | changed from to |
|---|
Передаю тикет Дмитрию.
Сейчас mod_conference_cdr_mysql при старте добавляет в таблицу cdr столбец startrecord (если его нет), после чего начинает работу, одновременно в фоновом режиме просматривает xml и апдейтит startrecord во всех записях, где есть запись.
comment:14 by , 8 years ago
| Owner: | changed from to |
|---|
Я поторопился с передачей тикета. Столбец-то в таблицу добавляется, а вот дальше при добавлении новых записей правильное значение в нем не устанавливается. Забираю тикет на доработку.
comment:17 by , 8 years ago
Replying to san:
Дима, а ты не забудь что пргорамма должна успешно искать записи в базе с новым столбцом и без него (для совместимости со старой базой)
Не сделанно
comment:18 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:19 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
r479
Теперь при неудаче запроса к базе данных с новым столбцом, используется старая версия запроса к БД.
comment:20 by , 8 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
В условии поиска записей переговоров используется время создания конференции, а не время начала записи. Таким образом, изложенная в описании тикета задача не выполнена.
comment:22 by , 8 years ago
Но возвращается время начала записи в поле startrecord.
Причина в том, что для SQL запроса, ограничения после WHERE я использовал рекомендованный запрос, который был мне выслан в одном из тикетов, и там стояло время создания конференции, так что я использовал это поле в своём запросе.
follow-up: 24 comment:23 by , 8 years ago
в тикете 388 вы написали
Предлагаю изменить условие запроса следующим образом:
WHERE UNIX_TIMESTAMP(endtime) >= 1473685200
AND UNIX_TIMESTAMP(starttime) <= 1473690659
AND has_record = 1
а надо было
Предлагаю изменить условие запроса следующим образом:
WHERE UNIX_TIMESTAMP(endtime) >= 1473685200
AND UNIX_TIMESTAMP(startrecord) <= 1473690659
AND has_record = 1
follow-up: 26 comment:24 by , 8 years ago
Replying to dimag:
в тикете 388 вы написали
Предлагаю изменить условие запроса следующим образом:
....
а надо было
....
Если Вы говорите, что надо было делать не так, как я предложил, а по-другому, то почему же Вы сделали, как я предложил, а не так, как было надо?
comment:25 by , 8 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
r496
Изменил SQL запрос вместо, starttime использую startrecord.
comment:26 by , 8 years ago
Replying to alx:
Если Вы говорите, что надо было делать не так, как я предложил, а по-другому, то почему же Вы сделали, как я предложил, а не так, как было надо?
Кроме этого, если посмотреть на изменения внесённые в r439(на которые жалуется Дмитрий), видно что и до этих изменений поиск был по starttime вместо startrecord.
Александр твоё мнение.