BiTel

Товарищи кто нибудь реализовывал у себя mutex группы договоров? Если да, то поделитесь решением, а то у меня сейчас принудительная проверка стоит ли группа, а потом включение выключение остальных, это слегка напрягает и впервую очередь меня.

mutex знаю, не понял, что нужно сделать.

Взаимное исключение, очевидно (mutual exclusion = mutex). Если договор состоит в группе А, то не может состоять в группе Б, я правильно понял?

Правильно.

не совсем понятно, что требуется,
одноразовую проверку,
или реалтайм механизм?

и почему именно группы?

угу ... мне, у которого юзеры строго по группам побиты вообще непонятен этот топик у меня мутекс изначально, by design


а в БГБ кроме групп нет никакой другой уникальной, групповой (простите за тавтологию) принадлежности
я когда-то предлагал группировать юзеров по тарифам - был послан ... в группы

есть sql запрос который может это делать бгг
а групп действительно мало для выявления какой то статистики.

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

для статистики можно использовать параметры

Потому что группы проще всего испльзовать в отчётах, в частности в уже созданных отчётах в модуле репорт.
Мне тут надобыл исхитриться и творить статистику с отчётами по трафковым и безлимитным тарифом. Логичным и наименее затратным стало добавление новых групп для привязки договоров к дополнительным группам.
Изначально же договоры были разбиты в группы по географическому признаку (города) и физическо/юридическому признаку. Теперь же все договоры имеют как минимум две группы географически юридическую и тарифную. Так что получается что существуют две группы групп которые теоретически (по логике) внутри должны бы быть мутексными, а фактически они сейчас, что хочешь то и делай.

В связи с вышеизложенным и появилась мысль-вопрос о создании определенных групп существующих по мутекс принципу. Реалтайм механизм это пожалуй слишком круто, а вот одноразовая проверка это вполне интересно-нормально.

одноразовый - простейших sql-запрос, там где выставлен бит А сбрасываем бит B

Только gr=gr&~<B>

в Разные SQL-запросы -> Работа с группами все есть, но человеку нужна именно "галочка" в клиенте

можно в договоре сделать параметр списковый с двумя значениями.... и обойтись без групп

кто-то из разработчиков (не помню кто именно) буквально недавно говорил что в API нет механизмов для работы со списковыми параметрами, не?

в данном контексте API и не нужно, вроде...

в случае групп при выборе А надо проверить не выбрана ли Б
в списке выбрать А и Б одновременно не возможно.

вот именно что вроде ... оно может им сейчас, в данный момент, не нужно, а завтра понадобится и что тогда делать?


спасибо, Капитан!