Автор Тема: Прямой доступ к БД  (Прочитано 4136 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн NA

  • Плагинописатель
  • Эксперт
  • ******
  • Сообщений: 906
  • Репутация +78/-20
    • Просмотр профиля
Прямой доступ к БД
« : 03 Июня 2010, 02:02:15 »

Попробовал сейчас из плагина зацепиться напрямую - то ли защита какая, то ли в плаге глюк *bm*, но:
- если компилирую плаг с созданием объекта враппера SQLite - плаг исчезает из всех меню (просто объявление Create!).
- перекомпилирую без создания объекта (но с подключенным враппером) - плаг снова появляется во всех меню.

Что странно и забавно, т.к. строка для меню запрашивается из GetTaskMenuCommandName, а объект враппера создается только в TaskMenuCommandExecute (т.е., на момент вывода меню вторая функция еще однозначно не активна).

Собственно, не очень-то и хотелось *bk* (поэкспериментировал на скорую руку по случаю),
но зато вспомнил, что вопрос с доступом к базе в API так и не решился.

На мой взгляд, имеет смысл внедрить в API
void AddInLT_SQL_Exec( LPCWSTR ) ( для всяческих CREATE INSERT UPDATE etc), а желательно, конечно, и
LPCWSTR AddInLT_SQL_Query( LPCWSTR ) (собсно SELECT, между рядами которого нуль, а плаг пусть сам режет на части).

Можно и объединить их, просто возвращать в первом случае в непустом тексте сообщение об ошибке, и пустую строку - если все ок.

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

Gantt... как много в этом слове. Оч ждется.

"Анонимному" минусишке: чем больше неудачников меня ненавидит, тем более правильно я живу. Твои минусы исподтишка - это настоящие плюсы мне. Спасибо!

Оффлайн Дмитрий Маслов

  • Администратор
  • Маэстро
  • *****
  • Сообщений: 6146
  • Репутация +220/-19
  • Я делаю мир таким!
    • Просмотр профиля
Re: Прямой доступ к БД
« Ответ #1 : 03 Июня 2010, 10:16:22 »
Для чего нужен прямой доступ к базе?

Оффлайн SkipUFO

  • Плагинописатель
  • Способный
  • ***
  • Сообщений: 109
  • Репутация +14/-0
    • Просмотр профиля
Re: Прямой доступ к БД
« Ответ #2 : 03 Июня 2010, 10:23:02 »
Как вариант можно было бы свои таблицы создавать внутри общей базы. Но тут возникает вопрос, как не повредить ядро программы.

Оффлайн Дмитрий Маслов

  • Администратор
  • Маэстро
  • *****
  • Сообщений: 6146
  • Репутация +220/-19
  • Я делаю мир таким!
    • Просмотр профиля
Re: Прямой доступ к БД
« Ответ #3 : 03 Июня 2010, 10:29:08 »
Как вариант можно было бы свои таблицы создавать внутри общей базы. Но тут возникает вопрос, как не повредить ядро программы.
Да, именно такая проблема.
Вопрос с хранением данных понятен, нужно придумать единый механизм хранения данных для всех плагинов и желательно чтобы база данных при этом не портилась.

Оффлайн SkipUFO

  • Плагинописатель
  • Способный
  • ***
  • Сообщений: 109
  • Репутация +14/-0
    • Просмотр профиля
Re: Прямой доступ к БД
« Ответ #4 : 03 Июня 2010, 10:46:12 »
Как вариант использование префиксов для именования таблиц плагина.
Возникает вопрос о создании некого механизма получения префикса (чтобы не было конфликтов между плагинами от разных разработчиков)

Оффлайн NA

  • Плагинописатель
  • Эксперт
  • ******
  • Сообщений: 906
  • Репутация +78/-20
    • Просмотр профиля
Re: Прямой доступ к БД
« Ответ #5 : 03 Июня 2010, 11:12:45 »
префиксы и GUIDы я тоже предлагал вначале.

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

Gantt... как много в этом слове. Оч ждется.

"Анонимному" минусишке: чем больше неудачников меня ненавидит, тем более правильно я живу. Твои минусы исподтишка - это настоящие плюсы мне. Спасибо!

Оффлайн NA

  • Плагинописатель
  • Эксперт
  • ******
  • Сообщений: 906
  • Репутация +78/-20
    • Просмотр профиля
Re: Прямой доступ к БД
« Ответ #6 : 05 Июня 2010, 01:27:48 »
Подумал насчет безопасной схемы. База должна быть общей, а таблицы пусть будут собственные.

А вот такой имхо должна быть организация работы плагов и API:

1. Однозначно надо давать возможность исполнять свой SQL, без этого не будет нужной гибкости.
2. API парсит запрос на имена изменяемых и создаваемых таблиц:
2.1 Таблица (c префиксом по имени плагина) И (неодноименная с зарезервированными) = можно писать.
2.2 Таблица (имеет зарезервированное имя) ИЛИ (не имеет префикса по имени вызывающего плагина) = SELECT-only.
3. Зарезервированными считаются как уже имеющиеся, так и планируемые имена таблиц LT.
4. Плагин имеет право создать N своих таблиц.

Список зарезервированных имен и количество собственных таблиц на один плагин публикуются в API.

Что получаем:
- разрушить базовые данные LT при таком подходе практически невозможно.
- не надо класть в папку Plugins отдельный SQLIte-сервер.
- получаем возможность гибкой работы с БД.
- если какой-то плагин перестал поддерживаться, намного проще создать его одноименную эмуляцию без потери данных. Но такие решения должны приниматься исключительно автором плагина + LTT. Полезно снова вспомнить про необходимость GUID каждого плагина (о чем я тоже писал еще давным-давно).

Отдельным плагинам (по спецрешению LTT и внесению этого исключения в бинарный код) можно разрешать и полный доступ к БД, но делать это в самых крайних случаях, по возможности обходясь обычными API-вызовами.



Попутно хочу уточнить, что lt_ в файловых именах плагинов LT мне видятся явным излишеством.
Отказ от этого префикса ничему не повредит, но позволит хранить названия таблиц хотя бы на 3 символа короче ;)
Приглашаю обсудить мои мечты о Контактах.

Gantt... как много в этом слове. Оч ждется.

"Анонимному" минусишке: чем больше неудачников меня ненавидит, тем более правильно я живу. Твои минусы исподтишка - это настоящие плюсы мне. Спасибо!

Оффлайн Do_zent

  • Мега Модератор
  • Опытный
  • *****
  • Сообщений: 597
  • Репутация +52/-0
    • Просмотр профиля
Re: Прямой доступ к БД
« Ответ #7 : 06 Июня 2010, 00:31:11 »
Подумал насчет безопасной схемы. База должна быть общей, а таблицы пусть будут собственные.
Нормально. Я за.