BiTel

да

ну и пусть себе не авторизовывает, деньги же сервер считает, и я не думаю что кому-то нужны в радиусе сессии которые не считаются, так что если сессии есть - пусть уж будут, а новые - в сад!

но если решишь не только "брать", но и "класть", то имхо прийдется писать и туда и туда во всяком случае текущие услуги все дублированы, типа contract_service это общий реестр, а npay_service это специфика с доп данными

P.S. кстати такие решения это нифига не правильно с точки зрения реляционной СУБД, в npay_service должен быть FK на contract_service и доп поля которых нет в contract_service, а так получается программирование на FoxPro 2.0, а не реляционная СУБД
а заодно бы и старый код не надо было ломать, не логично как то что абстрактный по сути метод ContractService.getContractServiceList не работает, это же не "getContractServiceListWithCount", достаточные для ответа данные в contract_service есть, должен бы и вернуть

С точки зрения реляционных СУБД у нас там много чего неправильного Например - конфигурации действий в XML файлах с id идентификаторами там и ссылки на эти идентификаторы из таблиц.
На мой взгляд, реляционный подход, равно как и все другие - не догма, а просто примеры удачных решений. И если можно поступиться примером с получением чётко осознаваемой выгоды - то так и делаем. Кроме того, поддержки FK не было в MyIsam таблицах, которые до недавнего времени да и сейчас широко используются.

Невозможна постоянная поддержка обратной совместимости без постепенного превращения API в бардак. Схема с привязкой модулей посредством услуг была некрасивая и мы её убрали, оставив услуги как разрешающие флаги для некоторых модулей.
Невозможно было полноценно добавить абонплату с указанием количества, используя эту схему всё равно.

1. ув. разработчики, думаю стоит перенести все сообщения начиная с этого поста в правильный раздел ... какой? npay? ядро? тут полагаю Вам виднее, т.к. после того поста речь больше идет об общем функционале и API нежели о трафике пропорционально периоду модуля dialup

2. я абсолютно согласен с Jimson в утверждении:

а то ведь у нас с вами что получается? contract.bean.ContractServiceManager.getContractServiceList(cid, mid) может вызываться радиусом, но ничего не знает об абонплатах, а npay.bean.ServiceObjectManager.getServiceObjectList(cid, -1, 0, 0) знает об абонплатах но не может вызываться радиусом, и, вполне возможно, ipn и др. модули тоже его использовать не смогут, а если смогут - напрашивается вопрос - почему они могу, а dialup не может? да, я понимаю что библиотеки нету, но, простите, зачем было ломать API, сделав его неработоспособным? или иначе - зачем API если все можно делать через SQL? пожалуйста, не поймите меня неправильно! мне нравится БГБ, мне нравится то что в нем есть API с помощью которого можно нарисовать что угодно, но мне чертовски не нравится что тот самый API, который является изюминкой БГБ, по сути биллингом в биллинге, ломается и все что работало годами сыпется как карточный домик

чего хотелось бы больше всего? очень, нет, _ОЧЕНЬ_ хотелось бы, чтобы contract.bean.ContractServiceManager.getContractServiceList(cid, mid) возвращал список абонплат пока Вы не сделаете то о чем писали несколько постов назад ... пусть внутри происходит все что угодно, но пока у радиуса нет возможности использовать классы npay - радиус должен иметь возможность работать с его услугами! радиус тоже человек и должен иметь право быть полноценной частью биллинга и использовать весь доступный API, IMHO

дабы расставить точки над i скажу - я не против работы с БД! но вознивкает вопрос - зачем мне API если я могу в базе все что надо сделать?

P.S. все же, как _правильно_ использовать не в phone? так:

или так:

тут Вы писали что надо использовать 0, но мануал не возражает и против -1 ... как _правильно_?

в смысле в myisam нельзя заставить tableB.FK использовать индекс по tableA.PK ?
фигово конечно, но все равно как то некрасиво так явно дублировать данные, к тому же центральная таблица contract_service это как бы столп биллинга, одно дело отпочковывать от нее специфики для разных модулей, другое дело явным образом дробить теряя связность с contract_service как это произошло с getContractServiceList

а что касается разростания API, так это же хорошо, когда любую задачу можно решить разными способами появляется простор для творчества

up

To snark:


- это вывод абонплат привязыванных именно к договору.


- это вывод абонплат без учёта фильтра по entry_id, т.е. как привязанных к самому договору так и привязанные к его поинтам и другим сущностям модулей (в перспективе)

По поводу получение списка услуг:
1) Как полумеру можно использовать старый бин и периодический вызов
пункта 12 инструкции по обновлению http://www.bgbilling.ru/v4.6/download/k ... om_4.5.txt
2) Как полумеру второго рода можно подсунуть архив npay.jar в lib BGRadiusDialup и работать с новым бином.
3) Также можно работать напрямую с БД.

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

Не правда. Навскидку - фабрика, "инстанцирующая" API разных версий.
Причем мы не просим вечную поддержку обратной совместимости. Просто нужно некоторое разумное время, что бы модернизировать скрипты, потому как изменения в API не всегда сводятся к тривиальному переименованию методов. Иначе преимущество BGB превращается в кошмар сопровождения.