MR2_3 SQL fixes

В первую очередь надо - перебрать SQL-и таким образом, чтобы с помощью накатывания всех custom_* на текущую YTDB получалась рабочая база. убрать лишнее - например данные вардена, обновы темплейтов и тп.

во вторых - взять конвертеры из 12268_01_mangos_dbscripts.sql и последующих и впихнуть их в отдельный файл (чтобы можно было пользовать поверх YTDB обнов)

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

rsa wrote:В первую очередь надо - перебрать SQL-и таким образом, чтобы с помощью накатывания всех custom_* на текущую YTDB получалась рабочая база. убрать лишнее - например данные вардена, обновы темплейтов и тп.

во вторых - взять конвертеры из 12268_01_mangos_dbscripts.sql и последующих и впихнуть их в отдельный файл (чтобы можно было пользовать поверх YTDB обнов)

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

1) Понятно, проблем быть не должно, простая чистка.
2) Там не коверторы... Есть вариант следующий: оставить родные таблицы базы нетронутыми, создать пустые новые таблицы (как раз отдельным файлом), в том же файле перегонять данные из родных таблиц в таблицы с новыми названиями. Перезапускать при каждом обновлении базы.
Минус - фактически в базе будет дубль каждой из этих скриптовых таблиц, т.к. сменилось только название, структура таблиц не изменялась.

там все далеко не так очевидно. Лично я один раз базу сделал, но второй раз повторить не смог пока :)
конверторы-перегонщики один хрен. можно даже через temptable сделать если надо, только чтобы без ручного вмешательства работало.

rsa wrote:там все далеко не так очевидно. Лично я один раз базу сделал, но второй раз повторить не смог пока :)
конверторы-перегонщики один хрен. можно даже через temptable сделать если надо, только чтобы без ручного вмешательства работало.

Хорошо... Прямо сейчас попробую сделать скули, чтобы база стала рабочей, после их накатывания.

Кстати, насчёт базы, почему не сделать создание скл по принципу как в тринити? дата_номер_база_название. мне кажется это будет по лучше чем в текущем варианте...

Sar777 wrote:Кстати, насчёт базы, почему не сделать создание скл по принципу как в тринити? дата_номер_база_название. мне кажется это будет по лучше чем в текущем варианте...

А по мне так привязка к ревизии удобнее. На триньке всегда путался с этими их апдейтами...

Написал два небольших скуль-апдейта на базу, если они есть в sql_mr и использовать auto_update.sh - база YTDB запускается без проблем. Теперь вычищать базу от старых и ненужных данных.
SQL 1

Code:

ALTER TABLE creature_template DROP COLUMN spell1, DROP COLUMN spell2, DROP COLUMN spell3, DROP COLUMN spell4;

SQL 2

Code:

DROP TABLE IF EXISTS dbscripts_on_creature_movement;
CREATE TABLE dbscripts_on_creature_movement SELECT * FROM creature_movement_scripts;
DROP TABLE IF EXISTS dbscripts_on_event;
CREATE TABLE dbscripts_on_event SELECT * FROM event_scripts;
DROP TABLE IF EXISTS dbscripts_on_go_use;
CREATE TABLE dbscripts_on_go_use SELECT * FROM gameobject_scripts;
DROP TABLE IF EXISTS dbscripts_on_go_template_use;
CREATE TABLE dbscripts_on_go_template_use SELECT * FROM gameobject_template_scripts;
DROP TABLE IF EXISTS dbscripts_on_gossip;
CREATE TABLE dbscripts_on_gossip SELECT * FROM gossip_scripts;
DROP TABLE IF EXISTS dbscripts_on_quest_end;
CREATE TABLE dbscripts_on_quest_end SELECT * FROM quest_end_scripts;
DROP TABLE IF EXISTS dbscripts_on_quest_start;
CREATE TABLE dbscripts_on_quest_start SELECT * FROM quest_start_scripts;
DROP TABLE IF EXISTS dbscripts_on_spell;
CREATE TABLE dbscripts_on_spell SELECT * FROM spell_scripts;

DELETE FROM command WHERE name LIKE 'reload all_scripts';
INSERT INTO command VALUES
('reload all_scripts',3,'Syntax: .reload all_scripts\r\n\r\nReload `dbscripts_on_*` tables.');

SQL 2 нужно перенакатывать при каждом обновлении базы.

Фиксы некоторых ошибок из скулей Р2 (в основном - спеллы): https://gist.github.com/4372445

Для фикса ошибок типа:

Code:

Creature (GUID: 221974) has spell 46598 defined in `auras` field in `creature_addon, but vehicle control spells are not suitable for _addon.auras handling`.

использовал такой скриптик (как я понимаю, ауры транспорта не должны висеть в аддонах):

Code:

UPDATE `creature_template_addon` SET `auras` = REPLACE(`auras`, '46598', '');
UPDATE `creature_template_addon` SET `auras` = REPLACE(`auras`, '  ', ' ');
UPDATE `creature_template_addon` SET `auras` = TRIM(`auras`);
UPDATE `creature_template_addon` SET `auras` = NULL WHERE `auras` = '';

UPDATE `creature_addon` SET `auras` = REPLACE(`auras`, '46598', '');
UPDATE `creature_addon` SET `auras` = REPLACE(`auras`, '  ', ' ');
UPDATE `creature_addon` SET `auras` = TRIM(`auras`);
UPDATE `creature_addon` SET `auras` = NULL WHERE `auras` = '';

Ну тут надо подставлять все ауры, на которые ругается.

Количество ошибок в консоли сильно-сильно уменьшилось =)

так вроде что-то подобное я пушил в скули. или нет?

rsa wrote:так вроде что-то подобное я пушил в скули. или нет?

В какой ветке??? Нет такого... Я обещал, что скулями займусь - занялся...
Что ещё требуется для дальнейшего развития?

P.S: Появилась идея, чтобы не перенакатывать SQL 2 после каждого апдейта базы - можно написать триггеры/процедуры, которые будут автоматом заполнять таблицы с новыми названиями при апдейте старых таблиц апами YTDB =)

эта идея бродила ХЗ сколько, кстати сейчас она вполне нужна (не думаю что Юрий будет менять формат тех же темплейтов крич :) Только кто бы занялся?

а менял я вот там - mr02420_mangos_creature_template_addon.sql

rsa wrote:а менял я вот там - mr02420_mangos_creature_template_addon.sql

Да нет, нет там ничего подобного...

rsa wrote:эта идея бродила ХЗ сколько, кстати сейчас она вполне нужна (не думаю что Юрий будет менять формат тех же темплейтов крич :) Только кто бы занялся?

Так я ж не против заняться этим, говорил не раз =)
Что именно нужно, очерти задачу только =)

Написал триггеры для одной таблицы (для других просто названия поправить и в нескольких местах название таблицы. Но меня сильно стало смущать то, что таблицы скриптов - без первичного ключа...
В общем, если надеяться на строгий формат обновлений YTDB - тогда триггеры к месту, а если обновления строк по этим таблицам в апах YTDB будут идти через указание произвольных полей - попа...
В общем, на ваш суд:

Code:

DROP TRIGGER IF EXISTS `cr_mov_scr_upd`;

CREATE TRIGGER `cr_mov_scr_upd` BEFORE UPDATE ON `creature_movement_scripts`
FOR EACH ROW
UPDATE dbscripts_on_creature_movement SET
delay = new.delay,
command = new.command,
datalong = new.datalong,
datalong2 = new.datalong2,
buddy_entry = new.buddy_entry,
search_radius = new.search_radius,
data_flags = new.data_flags,
dataint = new.dataint,
dataint2 = new.dataint2,
dataint3 = new.dataint3,
dataint4 = new.dataint4,
x = new.x,
y = new.y,
z = new.z,
o = new.o,
comments = new.comments
WHERE
id = old.id AND
command = old.command;

DROP TRIGGER IF EXISTS `cr_mov_scr_ins`;

CREATE TRIGGER `cr_mov_scr_ins` BEFORE INSERT ON `creature_movement_scripts`
FOR EACH ROW
INSERT INTO dbscripts_on_creature_movement VALUES (
new.id,
new.delay,
new.command,
new.datalong,
new.datalong2,
new.buddy_entry,
new.search_radius,
new.data_flags,
new.dataint,
new.dataint2,
new.dataint3,
new.dataint4,
new.x,
new.y,
new.z,
new.o,
new.comments
);

DROP TRIGGER IF EXISTS `cr_mov_scr_del`;

CREATE TRIGGER `cr_mov_scr_del` BEFORE DELETE ON `creature_movement_scripts`
FOR EACH ROW
DELETE FROM dbscripts_on_creature_movement WHERE id=old.id;

я задумал в скрипт обновления затолкать что-то вроде
rename table
create view (копию стандартного сделать из переименованной)
load YTDB update
drop view
rename table
только когда соберусь...

rsa wrote:я задумал в скрипт обновления затолкать что-то вроде
rename table
create view (копию стандартного сделать из переименованной)
load YTDB update
drop view
rename table
только когда соберусь...

Тоже как вариант. Но я не понимаю как это сделать =) Тем более никогда не работал с вьюхами (точнее не представляю, как вы собираетесь её использовать???) =)
Есть ещё какие задания/предложения для продолжения работы?

сделать-то несложно, вопрос надо ли...
а по предложениям - база по прежнему собирается плохо. в бранче-то нет ничего :) и лишних SQL-й там как было много так и осталось.
PS у меня на тестовом сервере только SSH. а веб - только на телефоне. так что перекинуть не получится :)

Ну я отдал скули на суд, если они принимаются - я могу залить. Но я тут накидал несколько вариантов, что влить, а что не надо? Я ответственности не люблю. =) Сделать сделал, что мог, а решение принимать или нет - за тобой =)
Что скажешь залить - хоть через минуту залью =)
Лишних файлов много? Вот этого не понял, чего там лишнего...

Чем ещё в ветке р3 я могу помочь? Что сделать, проверить???

KiriX wrote:что влить, а что не надо? Я ответственности не люблю. =)

я сейчас гавкать буду. у нас что, школьный урок с домашним заданием? кто за вас решать будет - надо оно или нет? считаете что правильно - вливайте. если будут проблемы - решим потом.
я тут вам не учитель/начальник и не могу заниматься всем и сразу, именно на этом (практике тыщи согласований каждого куска кода) и дохнут все серьезные проекты... тем более что я в скулях понимаю явно не больше вас.

rsa wrote:

KiriX wrote:что влить, а что не надо? Я ответственности не люблю. =)

я сейчас гавкать буду. у нас что, школьный урок с домашним заданием? кто за вас решать будет - надо оно или нет? считаете что правильно - вливайте. если будут проблемы - решим потом.
я тут вам не учитель/начальник и не могу заниматься всем и сразу, именно на этом (практике тыщи согласований каждого куска кода) и дохнут все серьезные проекты... тем более что я в скулях понимаю явно не больше вас.

Ну я так не привык - сначала на согласование, а потом принимается решение надо или нет =)
Ну хорошо - внесу, доступ для коммитов у меня там есть же вроде. Но как маркировать скули? mt_xxx?

да. утиль там уже лежит (git_id3, только скомпилять надо). автоапдейтер на mt_ я доделаю как руки дойдут.

Утилью никогда не пользовлся - всегда руками =) Тем более, что коммиты делаю на винде. Ну да ладно - попробуем =)