[patch]GOSSIP_NPC_FLAGS_CHECK
Вложений: 1
Ядро: 12157
Патч во вложении, копия http://paste2.org/p/2212329 Данный патч проверяет госсип меню на отсутствие пунктов с обязательными флагами в `gossip_menu_option`.`npc_option_npcflag`, которые есть в `creature_template`.`npcflag`. Пример: у нпц есть флаг UNIT_NPC_FLAG_BANKER, но нет пункта меню с таким флагом. |
Не сильно хорошо конечно что делается дополнительная выборка из базы, но тут зависит от сложности того же при пробежке по данным в памяти.
|
Я сначала начал писать патч, используя текущий цикл по оптионам, но в том варианте пришлось бы создавать массив для госсипа, в котором были бы все нпц, использующие госсип.
Далее надо было бы отслеживать начало и конец оптионов меню, суммировать флаги и при переходе к следующему меню делать проверку. На мой взгляд, данный патч намного проще и менее ресурсоемкий.. |
Имхо такие проверки надо наоборот убирать из ядра и переносить в базу.
|
В базу перенести такие проверки нельзя, это просто хранилище данных.:)
Если только речь идет о триггерах, функциях и процедурах. |
Как по мне данные в базе - дело самой базы. Если они не правильные - база не корректная, а значит с такой базой нельзя запускаться и работать. Как вариант отдельная тулза которая проверяет базу на наличие ошибок.
Меньше проверок - быстрее работает. |
База может больше чем просто хранилищем данных, смотря как ее использовать.
Данную проверку наверное нельзя реализовать триггером, но можно написать хранимую процедуру, которая будет проверять валидность данных в базе, и вызывать ее каждый раз при запуске (если в этом вообще есть смысл, в чем я сомневаюсь). |
zergtmn, если данный патч не нужен в ядре, тогда надо переместить тему в отвергнутые, права на это есть.:)
|
Дополнительные проверки целостности базы нужны. Так как сейчас они делаются при старте сервера то не вижу в чем проблема с патчем чтобы говорить об отвергнутых. Я просто задал вопрос нельзя ли их без гемороя сделать чисто в коде - вижу что нельзя. Так что у меня других замечаний по патчу нет.
|
В тринити это (если я правильно понял что тут делают) сделано проще. При построении меню есть проверка флагов
Код:
if (!(itr->second.OptionNpcflag & npcflags)) |
может не надо создавать тип, а использовать готовую коллекцию:
Код:
std::map<NPCFlags, char*> associative = std::map<NPCFlags, char*>(); |
Цитата:
|
Lordronn, в ядре есть подобная проверка:
Код:
if (gMenuItem.npc_option_npcflag & cInfo->npcflag) |
В ядре есть специальный режим опциональных проверок для базы - там всякие не всегда корректные результаты и т.д. Почему туда не перенести проверку раз она не влияет на работу сервера. Проверки базы делаемые всегда для того чтобы не дать загрузится некорректным значениям влияющим на работу сервера своим наличием.
Проверки на отсуnствующие данные могу быть и опциональными, чисто для девелоперов базы. |
Vladimir, я не осилил последний ваш пост.:)
Если бы знал, о чем речь, то сразу писал бы проверку там. |
Тогда уж может вести и отдельный лог, куда сразу будут складываться исправления?
Актуально, например, для исправления параметров в item_template да и ещё много чего можно пустить автоматом исправляться (ну или хотя бы выводить в отдельный лог запрос исправления). В целом же я согласен скорее с zergtmn и Evgeniy тем более, что реализовать такие проверки силами самой базы (через триггеры, процедуры) вполне возможно. Давно пора использовать все возможности MySQL, о чём совсем недавно и писал сам Shmoo =) |
KiriX, в данном случае нельзя сделать лог с исправлениями, т.к. оптионов нет, а телепаты в отпуске, чтобы сразу заложить все возможные варианты.:)
Насчет триггеров, функций и процедур: я давно уже поднимал вопрос об использовании этого функционала, но все осталось в ядре. Простой пример: удаление персонажа из базы. Если правильно настроить триггеры, то все записи будут автоматически удалены из связанных таблиц, не надо будет в ядре все это прописывать. Если ядро загнется в процессе удаления, то не факт, что целостность данных останется в норме. |
Цитата:
2) На счёт триггеров что-то как-то только говорят все (я не исключение =)), а фактически не делается. А было бы полезно. Даже базоделателям можно много чего полезного из это извлечь. 3) Именно этот простой пример я и привёл в той теме, где шму про возможности базы заговорил =) |
Кто-то говорит, а я во всю использую триггеры в своей работе.:)
Для мангоса пока не писал, т.к. при тесте патчей или работе над базой часто приходится накатывать базу с 0. Если будет необходимость, напишу, что потребуется. |
Цитата:
|
Для этого нужно создать отдельное обсуждение, а не флудить в топике патча.:)
|
Цитата:
|
To throw in an alternative:
For checks like the ones above we can use _only_ a sql-script with some SELECT output. Then there would no fancy output (that flag 2 == NPC_FLAG_QUESTGIVER), but the integrity check could be done as well. And it should be enough, as this is only really required to be used by DB-developers, not normal routine :) As example for this case here: Код:
diff --git a/contrib/dbIntegrityChecks/001_checkGossipOptionFlags.sql b/contrib/dbIntegrityChecks/001_checkGossipOptionFlags.sql |
Текущее время: 20:30. Часовой пояс GMT +3. |
ru-mangos.ru - Русское сообщество MaNGOS