Это что получается? Вместо 10 старых проблем добавилось 20 новых. И теперь в сборках 007, 008, 009 и т. д.. программисты НЕТАП будут их "героически" исправлять? Вообще есть надежда получить когда нибудь стабильный, безглючный релиз. Или продолжать авансировать обучение программеров НЕТАПА?Мне обещали после майских праздников, по потестив бетку 006 я думаю не раньше августа.. Во первых переход на 006 достаточно нетривиальный, походу прийдется перелопачивать почти все таблицы, пропала функция детального отчета через админку, но менюшка осталась, отчеты по трафику пока не стоятся никакие, грешу на несовпадение структуры таблиц, из транзакций удалили поле коммент добавили другое но не знаю надо ли переносить в него значения из бывшего коммент, убрали функционал дилера, достаточно много левых полей в базе погрохали, оптимизации по размерам полей нет никаких.
Сроки выхода 6-сборки UTM 5.2.1
Не надо устраивать панику. Функции отчетов вынесены в отдельный модуль liburfa-reports.so. Возможно у Вас он не загружен, проверьте utm5.cfg. В дефолтном конфиге строчка:Magnum72 писал(а): Мне обещали после майских праздников, по потестив бетку 006 я думаю не раньше августа.. Во первых переход на 006 достаточно нетривиальный, походу прийдется перелопачивать почти все таблицы, пропала функция детального отчета через админку, но менюшка осталась, отчеты по трафику пока не стоятся никакие, грешу на несовпадение структуры таблиц, из транзакций удалили поле коммент добавили другое но не знаю надо ли переносить в него значения из бывшего коммент, убрали функционал дилера, достаточно много левых полей в базе погрохали, оптимизации по размерам полей нет никаких.
urfa_lib_file=/netup/utm5/lib/utm5_core/liburfa-reports.so
присутствует.
Функционал дилера убран по причине его полной переработки. Новый модуль дилера с java-интерфейсом выйдет вместе с 006.
Структура базы была очищена от неиспользуемых с давних релизов полей, что давно надо было сделать.
По поводу сроков, как уже упоминали - после майских праздников.
serjk писал(а):Это хорошоMagnum72 писал(а): Структура базы была очищена от неиспользуемых с давних релизов полей, что давно надо было сделать.
По поводу сроков, как уже упоминали - после майских праздников.
Скрипт апдейта базы под 006 планируете сделать ?
При перестрийки таблицы discount_transactions_all надо ли переносить данные из comment в виде соответствующих цифровых значений в charge_type?
Планируете ли к релизу поправить индексы и размерность полей в таблицах?
Насчет скрипта - пока не вижу такой надобности, все решается средствами UTM5_*_update.sql (т.е. если в базе присутствовали и заполнялись левые поля, система их больше не использует, но и в базе они остаются, на новых базах этих полей не будет)Magnum72 писал(а): Это хорошо
Скрипт апдейта базы под 006 планируете сделать ?
При перестрийки таблицы discount_transactions_all надо ли переносить данные из comment в виде соответствующих цифровых значений в charge_type?
Планируете ли к релизу поправить индексы и размерность полей в таблицах?
Насчет comment - не обязательно.
Индексы будут, размерность полей пока не меняем.
Было бы приятно видеть sql-файлик или скрипт удаляющий ненужные больше поля.serjk писал(а):т.е. если в базе присутствовали и заполнялись левые поля, система их больше не использует, но и в базе они остаются, на новых базах этих полей не будет
Может быть не стоит делать это в UTM5_*_update.sql, а вынести в отдельный файл.
Понятно, что тот кому надо сделает это сам, но было бы очень мило с вашей стороны оказать такую любезность.
Я сделаю после релиза такой файлик, счас на основе беты это делать бесполезно.Arti писал(а):Было бы приятно видеть sql-файлик или скрипт удаляющий ненужные больше поля.serjk писал(а):т.е. если в базе присутствовали и заполнялись левые поля, система их больше не использует, но и в базе они остаются, на новых базах этих полей не будет
Может быть не стоит делать это в UTM5_*_update.sql, а вынести в отдельный файл.
Понятно, что тот кому надо сделает это сам, но было бы очень мило с вашей стороны оказать такую любезность.
Уважаемый XoRe.
Биллинг был куплен за ту цену которую за него запросил производитель, и ссылка что дешевое не может быть хорошим не прокатывают. По моему качество товара не должно зависеть от стоимости. Функционал, дополнительные удобства - согласен, но никак не стабильность работы. И отношение к клиентам по моему мнению не должно зависеть от толщины пачки мертвых президентов заплаченных за продукт.Ну... такой уж биллинг.
Здесь такое обращение к клиентам.
Если это вам не нравится, можете не использовать UTM и работать с другим биллингом.
2Utm3_user:
Уважаемый, вы неверно поняли мою позицию.
Я не защищаю и не оправдываю Netup.
Наоборот, я согласен с вами в ваших утверждениях.
Только толку от этого нет)
От ваших взглядов ситуация не меняется.
UTM - продукт своенравный, даже я бы сказал, своеобразный.
Выбрав его изза цены или изза сертификата, админу приходится обрабатывать его напильником и подпирать костылями.
В силу своих знаний и разумений естественно)
Но всегда есть выбор - купить другой биллинг.
UTM не одинок в своем ценовом диапазоне, можно выбрать что-то другое.
А можно купить что-нибудь подороже.
Я про этот выбор не забываю.
Думаю, большинство форуман - тоже.
У вас тоже есть этот выбор.
Уважаемый, вы неверно поняли мою позицию.
Я не защищаю и не оправдываю Netup.
Наоборот, я согласен с вами в ваших утверждениях.
Только толку от этого нет)
От ваших взглядов ситуация не меняется.
UTM - продукт своенравный, даже я бы сказал, своеобразный.
Выбрав его изза цены или изза сертификата, админу приходится обрабатывать его напильником и подпирать костылями.
В силу своих знаний и разумений естественно)
Но всегда есть выбор - купить другой биллинг.
UTM не одинок в своем ценовом диапазоне, можно выбрать что-то другое.
А можно купить что-нибудь подороже.
Я про этот выбор не забываю.
Думаю, большинство форуман - тоже.
У вас тоже есть этот выбор.
Еще небольшое предложение по INSERT в discount_transactions_all
Запросы ядра как будто специально сделаны для уменьшения производительности системы. К примеру?
INSERT INTO discount_transactions_all(account_id,incoming_rest,outgoing_rest,discount,discount_without_tax,
discount_with_tax,service_id,service_type,slink_id,discount_date,comment,discount_period_id) VALUES('557','304.4373128414145','304.4373128414145','0','0','0',
'96','3','2420','1209763865','IP discount','53825')
Согласно мануалу стоимость INSERT в мускуле распределяется так:
Connecting: (3)
Sending query to server: (2)
Parsing query: (2)
Inserting record: (1 x size of record)
Inserting indexes: (1 x number of indexes)
Closing: (1)
В данном запросе мы видим Максимум для нагрузки на "Sending query to server: (2)" и "Parsing query: (2)".
А аналогичный запрос лишен этих недостатков:
INSERT INTO discount_transactions_all VALUES('557','304.4373128414145','304.4373128414145','0','0','0',
'96','3','2420','1209763865','IP discount','53825')
Только надо значения в правильном порядке расставлять (в оригинальном к примеру порядок полей не совпадает с структурой таблицы - чтоб парсер посильнее нагрузить
Запросы ядра как будто специально сделаны для уменьшения производительности системы. К примеру?
INSERT INTO discount_transactions_all(account_id,incoming_rest,outgoing_rest,discount,discount_without_tax,
discount_with_tax,service_id,service_type,slink_id,discount_date,comment,discount_period_id) VALUES('557','304.4373128414145','304.4373128414145','0','0','0',
'96','3','2420','1209763865','IP discount','53825')
Согласно мануалу стоимость INSERT в мускуле распределяется так:
Connecting: (3)
Sending query to server: (2)
Parsing query: (2)
Inserting record: (1 x size of record)
Inserting indexes: (1 x number of indexes)
Closing: (1)
В данном запросе мы видим Максимум для нагрузки на "Sending query to server: (2)" и "Parsing query: (2)".
А аналогичный запрос лишен этих недостатков:
INSERT INTO discount_transactions_all VALUES('557','304.4373128414145','304.4373128414145','0','0','0',
'96','3','2420','1209763865','IP discount','53825')
Только надо значения в правильном порядке расставлять (в оригинальном к примеру порядок полей не совпадает с структурой таблицы - чтоб парсер посильнее нагрузить
2Kayfolom:
А вот тут так и надо.
Выигрыш производительности тут незначительный.
Не верите - запустите 1 000 000 инсертов таким и таким образом.
Более того, я думаю даже без указания колонок, mysql все равно их запрашивает.
Попробуйте запустить INSERT с количеством значений бОльшим, чем колонок в таблице - mysql вернет ошибку, т.к. не вставляет тупо, а смотрит чего и куда вставляет.
С другой стороны без указания полей нет гибкости запросов и легко запутаться и наделать новых багов.
А баги тут совсем ни к чему =)
А вот тут так и надо.
Выигрыш производительности тут незначительный.
Не верите - запустите 1 000 000 инсертов таким и таким образом.
Более того, я думаю даже без указания колонок, mysql все равно их запрашивает.
Попробуйте запустить INSERT с количеством значений бОльшим, чем колонок в таблице - mysql вернет ошибку, т.к. не вставляет тупо, а смотрит чего и куда вставляет.
С другой стороны без указания полей нет гибкости запросов и легко запутаться и наделать новых багов.
А баги тут совсем ни к чему =)
+1XoRe писал(а):2Kayfolom:
А вот тут так и надо.
Выигрыш производительности тут незначительный.
Не верите - запустите 1 000 000 инсертов таким и таким образом.
Более того, я думаю даже без указания колонок, mysql все равно их запрашивает.
Попробуйте запустить INSERT с количеством значений бОльшим, чем колонок в таблице - mysql вернет ошибку, т.к. не вставляет тупо, а смотрит чего и куда вставляет.
С другой стороны без указания полей нет гибкости запросов и легко запутаться и наделать новых багов.
А баги тут совсем ни к чему =)
Если разработчики так сделают я не смогу юзать свои поля в табличках...
Недавно обнаружиал такой косяк в скриптах упдейта мускула, вообще надо сказать что ранее в них не заглядывал, просто юзал.
До тех пор пока не наступил на мину заложеную разработчтиками еще в начале 41 года.
Суть мины такая - если база уже есть, то ее поля не модифицируются.
База стоит с незапамятной сборки утм 5.
размерность полей с тех пор осталась неизменной , кримеру поле mac в ip_groups имела размерность 12, собственно понятно к чему это приводило.
Я не стал просматривать другие мины , просто пропарсил UPDATE.sql и сного запустил.
До тех пор пока не наступил на мину заложеную разработчтиками еще в начале 41 года.
Суть мины такая - если база уже есть, то ее поля не модифицируются.
База стоит с незапамятной сборки утм 5.
размерность полей с тех пор осталась неизменной , кримеру поле mac в ip_groups имела размерность 12, собственно понятно к чему это приводило.
Я не стал просматривать другие мины , просто пропарсил UPDATE.sql и сного запустил.