|
Начинаем работу
| |
| VV123 | Дата: Суббота, 07.05.2016, 16:11 | Сообщение # 121 |
|
Генерал-майор
Группа: Проверенные
Сообщений: 304
Статус: Offline
| Цитата drserj (  ) да я, как-бы, не отслеживаю структуру баз, специально сделал возможность правки импорта, делайте что хотите. Если надо перепаковать инсталл - скажете. Цитата drserj ( ) с чего бы? все модули импорта-экспорта - плагины.  Засада в следующем:
1) у ряда полей не возможно изменить название т.к. они отсутствуют в языковых файлах.
2) у полей с хешами (возможно еще у каких) не возможно сменить тип столбца при создании таблиц main и detail, ошибка при импорте базы.
По ходу выяснилось что при добавлении в интерфейсе поля eDonkey, ошибка Access Violation.
3) добавить еще десяток полей при создании таблицы detail типа reserv1, reserv2 ... reserv9 с возможностью менять названия в языковых файлах и тип.
Еще не понятно, зачем было делать:
ALTER ignore TABLE `description` CHANGE `TimeLastModified` `LastModified` TIMESTAMP;
ALTER IGNORE TABLE `topics` CHANGE `topic_descr` `topic` VARCHAR(500);
почему нельзя было эти таблицы оставить в неизменном виде?
В новой структуре удалено поле Filename, решение есть при импорте базы, но правильнее внести изменения в программу, а то файлы сваливаются в корень .\lib\ без подкаталогов.
Можно отказаться от "and COALESCE(lang,"ru")="ru" в запросе если добавить в таблицу topics два значения "ru" и "en" в поле lang с пустыми ячейками в оставшихся полях.
|
| |
| |
| drserj | Дата: Суббота, 07.05.2016, 17:45 | Сообщение # 122 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Цитата VV123 ( ) 1) у ряда полей не возможно изменить название т.к. они отсутствуют в языковых файлах.
примеры, плз, может где-то промахнулся...
Цитата VV123 ( ) не возможно сменить тип столбца при создании таблиц
естественно... при смене типа данных надо и программу изменять... кто ж спорит...
Цитата VV123 ( ) добавить еще десяток полей
а кто обрабатывать эти поля будет, если сама программа о них не знает ??? прийдется и программу менять...
Цитата VV123 ( ) почему нельзя было эти таблицы оставить в неизменном виде?
видимо не просто так, уже не помню, возможно, унифицировал что-то... хотя, какая разница, как я обозвал поле. Ни на работе программы, ни на импорте это не отражается...
Цитата VV123 ( ) правильнее внести изменения в программу
возможно, надо смотреть...
Цитата VV123 ( ) Можно отказаться от "and COALESCE(lang,"ru")="ru"
и что изменится? я старался не вносить изменения в сами данные... если это критично - можно и изменить...
Вообще, я не хочу делать что-либо, пока структура базы окончательно и бесповоротно не устаканится. Самое неблагодарное дело вносить постоянные изменения в программу,особенно, в плане изменения структуры БД. Ты видишь только наружную сторону. А теперь подумай, сколько изменений надо внести в программу изменив только одно поле? Поиск динамический - во всех местах правим. В таблице отобразить - правим толпу кода, правим кучу настроек таблиц, сами настройки, десятки форм, где это используется, экспорты, импорты, языковые модули и т д....
Остановитесь, выберите оптимальные параметры и структуру базы и я по свободе внесу исправления.
Боле того, да разгребите вы наконец авторов, серии, темы... Полнотекстовый поиск - хорошо, но не достаточно. Создайте списки авторов, серий, тем... И база в несколько раз меньше станет и проблем меньше.
И вообще, у вас же есть такие талантливые, мужественные, берущие всё под карандаш, полностью подконтрольные сообществу, пишущие за пару недель программы великие гуру...
drSerj
|
| |
| |
| VV123 | Дата: Суббота, 07.05.2016, 18:39 | Сообщение # 123 |
|
Генерал-майор
Группа: Проверенные
Сообщений: 304
Статус: Offline
| Цитата drserj ( ) примеры, плз, может где-то промахнулся... Цитата drserj ( ) хотя, какая разница, как я обозвал поле. Ни на работе программы, ни на импорте это не отражается...
Цитата drserj ( ) а кто обрабатывать эти поля будет, если сама программа о них не знает ??? прийдется и программу менять... Цитата drserj ( ) Вообще, я не хочу делать что-либо, пока структура базы окончательно и бесповоротно не устаканится. Самое неблагодарное дело вносить постоянные изменения в программу,особенно, в плане изменения структуры БД.
Даже можно не добавлять, но иметь возможность сменить тип и название при создании таблиц main и detail. Вот сейчас хаши переехали в отдельную таблицу и появились несколько других полей, но я не могу их импортировать потому что у освободившихся из под хешей полей не возможно сменить тип и название.
Вот вышеизложенное сделать и еще кое-что и можно будет на несколько лет забыть о просьбах трудящихся
|
| |
| |
| drserj | Дата: Суббота, 07.05.2016, 19:24 | Сообщение # 124 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Цитата VV123 ( ) Ну вот я и прошу зарезервировать поля и возможность менять их тип
А вот это - маловероятно... как ты себе это представляешь???? Зарезервировать - еще куда ни шло, а вот с возможностью менять на ходу тип - это слишком...
Цитата VV123 ( ) Вот сейчас хаши переехали в отдельную таблицу и появились несколько других полей, но я не могу их импортировать потому что у освободившихся из под хешей полей не возможно сменить тип и название.
а на ходу привести к структуре программы никак? Ну переехали у вас кеши в другую таблицу, получилась в моей таблице в поле дыра, ну сделай update и выкинь потом отдельную таблицу хеша.... или я что-то не понял?
Цитата VV123 ( ) и можно будет на несколько лет забыть о просьбах трудящихся
гы.... а что мешает мне это сделать сейчас ??? (эт так, к слову) :)
вобшем, я посоветуюсь с народом (спецами по БД) по поводу смены типа поля без переписывания кода... может я уже отупел и чего-то не знаю (всё возможно), если это прокатит без бубна - будем обсуждать дальше...
drSerj
|
| |
| |
| VV123 | Дата: Суббота, 07.05.2016, 19:48 | Сообщение # 125 |
|
Генерал-майор
Группа: Проверенные
Сообщений: 304
Статус: Offline
| Цитата drserj ( ) а вот с возможностью менять на ходу тип - это слишком...
Вот сейчас например есть `eDonkey` char(32) (напомню, ошибку вызывает) а я в место него хочу новый `Tags`VARCHAR(500).
Пускай он там внутри программы так и зовется `eDonkey`, в языковом файле я ему меняю название на "Тэги", в файле lib.convert.sql тип на
`eDonkey` VARCHAR(500) и усё :).
Но пока так не получается, в языковом файле названия этого поля нет, при смене типа - ошибка при импорте базы  .
И вот что интересно, например `CRC32` char(8) легко превратился в `CRC32` varchar(300) и в языковом файле я ему поменял название.
Сообщение отредактировал VV123 - Суббота, 07.05.2016, 19:54 |
| |
| |
| drserj | Дата: Суббота, 07.05.2016, 20:44 | Сообщение # 126 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Цитата VV123 ( ) Зачем на ходу, в файле lib.convert.sql при создании таблиц main и detail.
Я имел в виду то, что прийдется без переписывания кода менять типы данных...В файле, в базе - да, а вот в программе - вряд ли....
Цитата VV123 ( ) `CRC32` char(8) легко превратился в `CRC32` varchar(300)
это да, фактически, строка в строку - возможно, но и тут - не всегда... Я напоминаю, помимо SQL имеется еще и делфи
drSerj
|
| |
| |
| VV123 | Дата: Суббота, 07.05.2016, 21:13 | Сообщение # 127 |
|
Генерал-майор
Группа: Проверенные
Сообщений: 304
Статус: Offline
| Цитата drserj ( ) это да, фактически, строка в строку - возможно, но и тут - не всегда...
но вот что мне непонятно это каким местом код в программе оказался зависим от типа данных в таблице
|
| |
| |
| drserj | Дата: Воскресенье, 08.05.2016, 17:20 | Сообщение # 128 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Цитата VV123 ( ) но вот что мне непонятно это каким местом код в программе оказался зависим от типа данных в таблице
то есть как это каким ???? в таблице - каждой колонке (полю) указывается тип, при любом обращении к базе - каждому данному указывается тип, при составлении любого запроса - учитывается тип (хотя бы для расстановки кавычек и т д), любая обработка - учитывается тип... Т.е. любая смена типа в поле базы влечет за собой переписку туевой хучи кода.... Увы, реалии таковы. И если кто-то считает, что можно взять и просто написать программу абсолютно не учитывая типы - мне остается только тихо улыбаться по этому перелопачивать каждый раз ~15.500 строк чисто моего кода плюс около 40 форм с десятками тысяч элементов - увольте...
Цитата VV123 ( ) Цитата drserj ()примеры, плз, может где-то промахнулся...
`AICH`, `DDC`, `Doi`, `Googlebookid`, `ID`, `ISSN`, `LCC`, `Local`, `MD5`, `OpenLibraryID`, `SHA1`, `TTH`, `eDonkey`
Это не есть переводимые аббревиатуры... по этому и в языковых файлах отсутствуют за ненадобностью...
drSerj
|
| |
| |
| VV123 | Дата: Воскресенье, 08.05.2016, 19:42 | Сообщение # 129 |
|
Генерал-майор
Группа: Проверенные
Сообщений: 304
Статус: Offline
| "Давайте не будем нервничать и спокойно во всем разберемся" :)
Итак, с типами все в порядке, проблема из-за одного поля eDonkey, как писал выше при добавлении в настройки\интерфейс в список полей таблицы вызывает ошибку
Цитата drserj ( ) Это не есть переводимые аббревиатуры... по этому и в языковых файлах отсутствуют за ненадобностью...
добавить десяток "резервных" полей наверное сложно, согласен, нужно прописывать во все формы, если сделаешь будет великолепно.
|
| |
| |
| drserj | Дата: Воскресенье, 08.05.2016, 21:38 | Сообщение # 130 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| http://libruslib.ucoz.com/libgen/LIBGEN_2.0b_160507.RAR
исправлена ошибка с полем eDonkey
добавлена возможность изменения наименований полей:
f1_1124="ID"
f1_1125="eDonkey"
f1_1126="AICH"
f1_1127="SHA1"
f1_1128="TTH"
f1_1129="Local"
f1_1130="ISSN"
f1_1131="DDC"
f1_1132="LCC"
f1_1133="Doi"
f1_1134="Googlebookid"
f1_1135="OpenLibraryID"
drSerj
|
| |
| |
| VV123 | Дата: Понедельник, 09.05.2016, 03:30 | Сообщение # 131 |
|
Генерал-майор
Группа: Проверенные
Сообщений: 304
Статус: Offline
| Спасибо!
f1_1123="Статус" что за поле?
после него все съехало на одну позициюДобавлено (09.05.2016, 01:30)
---------------------------------------------
должно быть так:
f1_1124="eDonkey"
f1_1125="AICH"
f1_1126="SHA1"
f1_1127="TTH"
f1_1128="Local"
f1_1129="ISSN"
f1_1130="DDC"
f1_1131="LCC"
f1_1132="Doi"
f1_1133="Googlebookid"
f1_1134="OpenLibraryID"
а вот ID куда-то потерялся
|
| |
| |
| drserj | Дата: Понедельник, 09.05.2016, 17:49 | Сообщение # 132 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| http://libruslib.ucoz.com/libgen/LIBGEN_2.0b_160508.RAR
drSerj
|
| |
| |
| VV123 | Дата: Вторник, 10.05.2016, 13:15 | Сообщение # 133 |
|
Генерал-майор
Группа: Проверенные
Сообщений: 304
Статус: Offline
| Спасибо!
Даже закачка архивов исправлена!
остались мелочи:
1) в базе убрали поле Filename, файлы сваливаются в корень .\lib\ без подкаталогов. В программе это поле надо оставить, но сделать так чтобы программа сама формировала путь к файлу из полей id и md5.
2) при актуализации, если сняты все чекбоксы "писать в лог", создается лог файл нулевого размера.
3) таблицы description и topics оставлять в неизменном виде при импорте в базу, чтобы отказаться от:
ALTER ignore TABLE `description` CHANGE `TimeLastModified` `LastModified` TIMESTAMP;
ALTER IGNORE TABLE `topics` CHANGE `topic_descr` `topic` VARCHAR(500);
Возможно ли при импорте базы управлять какие таблицы конвертировать, а какие пропустить?
|
| |
| |
| drserj | Дата: Вторник, 10.05.2016, 20:59 | Сообщение # 134 |
|
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Статус: Offline
| Цитата VV123 ( ) Даже закачка архивов исправлена!
Если и исправлена, то раньше.
Цитата VV123 ( ) остались мелочи:
угу... помню я эти мелочи в прошлый раз...
Цитата VV123 ( ) В программе это поле надо оставить
зачем, если оно пустое?
Цитата VV123 ( ) 2) при актуализации, если сняты все чекбоксы "писать в лог", создается лог файл нулевого размера.
не вижу особых проблем, посмотрю...
Цитата VV123 ( ) 3) таблицы description и topics оставлять в неизменном виде
ну чё оно тебя так прет???? какая разница, как я внутри программы назвал поля ???
Цитата VV123 ( ) Возможно ли при импорте базы управлять какие таблицы конвертировать, а какие пропустить?
править файл импорта, по идее...
1. кстати, какая ссылка на актуальную базу?
2. зачем п.1, если скачку отрубили???
drSerj
|
| |
| |
| VV123 | Дата: Вторник, 10.05.2016, 21:56 | Сообщение # 135 |
|
Генерал-майор
Группа: Проверенные
Сообщений: 304
Статус: Offline
| Цитата drserj ( ) угу... помню я эти мелочи в прошлый раз...
Цитата drserj ( ) зачем, если оно пустое?
Цитата drserj ( ) какая разница, как я внутри программы назвал поля ???
есть такой http://libgen.io/dbdumps/libgen_dbbackup-last.rar в нем нет таблица topics и description
в зависимости от того есть таблица или нет нужно либо "ALTER ignore TABLE" либо "-- ALTER ignore TABLE"
пробовал добавлять IF EXISTS не работает, или я не знаю как правильно
есть такой http://libgen.io/dbdumps/libgen_dbbackup-last-all-2016-05-07.rar в нем есть все таблицы
но импорт базы занял часов 6 из-за не нужных огромных таблиц *_edited
вот если добавить возможность указывать какие таблицы из файла бэкапа импортировать, ведь есть же процедура подготовки к загрузке в базу в которой выкидывется создание индексов
Цитата drserj ( ) 2. зачем п.1, если скачку отрубили???
Цитата drserj ( ) ну чё оно тебя так прет???? |
| |
| |
|
Главная 
