SQLite и базы данных в Lazarus

[Сергей Смирнов]

Собственно тема навеяна довольно безрадостными рассуждениями на тему невозможности использования DataModule в DesignTime.

Так вот. Проблема имеет место быть и начнёт решаться только после релиза Lazarus 1.0, который все и так уже устали ждать. В чисто практической плоскости это означает, что ждать милостей от природы (в смысле - от разработчиков) не приходится. Значит, нужна какая-то подпорка, которая позволила бы хотя бы частично снять проблему.

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

Однако надо на чём-то отработать технологию. И тут мы переходим к первой части темы. Чем хорош SQLite: он удобен, быстр и имеет очень простой и понятный API, в отличие, скажем, от FireBird/Interbase. Его популярность очень высока, по крайней мере, за границей.

Отсюда вопрос: а у нас этот самый SQLite кому-нибудь интересен? Кто-нибудь рассматривает его как движок БД для приложений локального масштаба? Есть смысл разбираться с его, так мягко скажем, особенностями и дорабатывать существующий компонент для Lazarus (либо делать новый "с нуля")?

[Yogrik]

Ух....как удачно заглянул....


Да, есть люди которые использую sqlite для локальных
приложений...


Я даже готов помоч, чем смогу...
Но могу не многое, всеж студент как ни как...

Ну и сами понимаете с временем тоже не ахти....

Но всеже помочь готов...!!!!

[Сергей Смирнов]

Я даже готов помоч, чем смогу...
Но могу не многое, всеж студент как ни как...

Ну и сами понимаете с временем тоже не ахти....

Но всеже помочь готов...!!!!

Это хорошо, спасибо! Ничего слишком уж серьёзного делать, я думаю, не придётся. Там толпе народу просто делать нечего. Может быть потестить что-нибудь, пообсуждать, поделиться опытом использования SQLite, подумать, как обойти некоторые его странные фичи, а может даже использовать их во благо. Моральная поддержка тоже приветствуется

[debi12345]

Однако надо на чём-то отработать технологию. И тут мы переходим к первой части темы. Чем хорош SQLite: он удобен, быстр и имеет очень простой и понятный API, в отличие, скажем, от FireBird/Interbase. Его популярность очень высока, по крайней мере, за границей.
...
Отсюда вопрос: а у нас этот самый SQLite кому-нибудь интересен? Кто-нибудь рассматривает его как движок БД для приложений локального масштаба?

Очень хороший и компактный движок, с поддержкой триггеров, индексов и юникода, нереально компактный ( одна DLL размером 230 К ), и невероятно быстрый.

Есть смысл разбираться с его, так мягко скажем, особенностями и дорабатывать существующий компонент для Lazarus (либо делать новый "с нуля")?

Вопрос уже поднимался - по части FreePascal SQLDB. Не надо с нуля. А надо перевести его на чистый SQL - то бишь реализовать интерфейс по типу PostgreSQL ( взять за прототип PQCONNECTION.PP ). Тогда и странности ( в основном места вызова обработчиков событий ) исчезнут.

[Сергей Смирнов]

Вопрос уже поднимался - по части FreePascal SQLDB. Не надо с нуля. А надо перевести его на чистый SQL - то бишь реализовать интерфейс по типу PostgreSQL ( взять за прототип PQCONNECTION.PP ). Тогда и странности ( в основном места вызова обработчиков событий ) исчезнут.

Надо - не надо -- это ещё надо разбираться. В текущей реализации пока есть некоторые недоработки, в том числе и довольно глобальные. Можно ли их устранить не переделывая всё с нуля -- большой вопрос. Собственно, сам автор пока толком не знает.

Что до странностей, то я имел ввиду несколько другое. SQLite реализует очень странную типизацию данных: не на уровне метаданных (в смысле типов полей), а на уровне хранения, причём в одном поле могут спокойно соседствовать данные разных типов. Особенно сильно это влияет на данные типа даты. Кроме того нет никакой возможности получить тип поля в запросе, если оно не является простой ссылкой на поле таблицы. Например, получить тип вычисляемого поля запроса - в частности любой групповой функции - невозможно до считывания первой строки данных (а её может и не быть) и даже после этого определить тип точно всё равно нельзя, если это, скажем, дата/время. Вот такие трудности. А места вызова обработчиков событий по сравнению с этим - просто пустяки.

[debi12345]

Что до странностей, то я имел ввиду несколько другое. SQLite реализует очень странную типизацию данных: не на уровне метаданных (в смысле типов полей), а на уровне хранения, причём в одном поле могут спокойно соседствовать данные разных типов. Особенно сильно это влияет на данные типа даты. Кроме того нет никакой возможности получить тип поля в запросе, если оно не является простой ссылкой на поле таблицы. Например, получить тип вычисляемого поля запроса - в частности любой групповой функции - невозможно до считывания первой строки данных (а её может и не быть) и даже после этого определить тип точно всё равно нельзя, если это, скажем, дата/время. Вот такие трудности. А места вызова обработчиков событий по сравнению с этим - просто пустяки.

Именно поэтому и говорю - нужно перевести SQLite3 на SQLDB. Потому что "там" можно обойти ограничение на автораспознавание типа полей, так как типом данных можно управлять через явное указание типа, работая с persistent-полями ( ftBoolen = ftInteger, etc ). А саму конверсию по ЯВНО указанному типу - перепоручить TSQLite3Connection - аналогично TPQConnection, где используется API самого DB-баскенда.

Кстати, сейчас такая же петрушка и с параметрами запросов у всех прочих DB-баскендов, и ничего - живем, опять-таки явно указывая типы данных запрашивамых параметров, или устанавливая их значения как "{parameter}.as{type}:= {value}".

[Сергей Смирнов]

Именно поэтому и говорю - нужно перевести SQLite3 на SQLDB. Потому что "там" можно обойти ограничение на автораспознавание типа полей, так как типом данных можно управлять через явное указание типа, работая с persistent-полями ( ftBoolen = ftInteger, etc ). А саму конверсию по ЯВНО указанному типу - перепоручить TSQLite3Connection - аналогично TPQConnection, где используется API самого DB-баскенда.

Собственно, а чего там переводить? Редактор полей (FieldDefs) является частью инфраструктуры стандартного доступа к данным как в Дельфи, так и в Лазаре. Я не понимаю, как автору существующего SQLite3 датасета удалось это дело прибить. Однако создавать каждый раз список полей - довольно геморно. Надо бы что-нибудь придумать.

Кстати, сейчас такая же петрушка и с параметрами запросов у всех прочих DB-баскендов, и ничего - живем, опять-таки явно указывая типы данных запрашивамых параметров, или устанавливая их значения как "{parameter}.as{type}:= {value}".

Это неизбежно, в том числе и в Дельфи так было.

[debi12345]

Редактор полей (FieldDefs) является частью инфраструктуры стандартного доступа к данным как в Дельфи, так и в Лазаре. Я не понимаю, как автору существующего SQLite3 датасета удалось это дело прибить.

Но чтобы это пахало, нужно опять-таки :

А саму конверсию по ЯВНО указанному типу - перепоручить TSQLite3Connection - аналогично TPQConnection, где используется API самого DB-баскенда.

то бишь прописать код конверсии - LoadFields etc.

Кстати, в SQLite3 последних сборок много чего доработано - кажется, и по части типов данных из пустых запросов в том числе. Проект ( SQLite3 )очень быстро прогрессирует.

Однако создавать каждый раз список полей - довольно геморно. Надо бы что-нибудь придумать.

Кому как. Во-первых, даже сейчас - проблема возникает только на некоторых типах вроде даты и булевых.
Во-вторых, лично я создаю persistent-поля очень часто - для настройки ProviderFlags, для доступа к удобному сервису вроде AsSQL ( значение в виде, готовом для конкатенации с SQL.Text - в MSEgui ), для доступа к ним в DesignTime, да и сам доступ к ним быстрее - сразу по адресу, вместо перебора по fieldbyname('fname'), что весьма заметно при большом кол-ве записей.

[Сергей Смирнов]

Но чтобы это пахало, нужно опять-таки :

А саму конверсию по ЯВНО указанному типу - перепоручить TSQLite3Connection - аналогично TPQConnection, где используется API самого DB-баскенда.

то бишь прописать код конверсии - LoadFields etc.

Надо будет глянуть... хотя, кажись, ничего там делать не надо вообще.

Кстати, в SQLite3 последних сборок много чего доработано - кажется, и по части типов данных из пустых запросов в том числе. Проект ( SQLite3 )очень быстро прогрессирует.

Вот это уже интересно. У меня 3.3.7 - там всё плохо.

Кому как. Во-первых, даже сейчас - проблема возникает только на некоторых типах вроде даты и булевых.
Во-вторых, лично я создаю persistent-поля очень часто - для настройки ProviderFlags, для доступа к удобному сервису вроде AsSQL ( значение в виде, готовом для конкатенации с SQL.Text - в MSEgui ), для доступа к ним в DesignTime, да и сам доступ к ним быстрее - сразу по адресу, вместо перебора по fieldbyname('fname'), что весьма заметно при большом кол-ве записей.

Эээ... ну я ничем таким не пользовался, ничего не понял, но было интересно

[debi12345]

то бишь прописать код конверсии - LoadFields etc.

Надо будет глянуть... хотя, кажись, ничего там делать не надо вообще.

Для Date[Time] и Boolean потребуется 100% ( они сохраняются нормально, учавствуют в операциях тоже - но представляются нестандартно ). Есть еще проблема с Boolean-полями - в них True=1, поэтому сравнение с 't'/'f' дает левые результаты.

Лично я вижу (TSqlite3Dataset & TSQLite3Connection) как переведенные на другое API PostgreSQL-братья.

[debi12345]

Есть еще проблема с Boolean-полями - в них True=1, поэтому сравнение с 't'/'f' дает левые результат

Вообще-то BOOLEAN-поля принимают и "=1" и "='t'", причем и сохраняет в таком же виде, и в операциях использует. По идее, для соместимости с SQL-диалектом - нужно остановиться на 't/f' варианте, и контроллировать ( и конвертировать ) как раз через процедуры адаптации в "tsqlite3connection.pp". Но как быть с присвоениями, делаемыми в SQL-запросах, минуя FPC-продедуры, типа :

insert into t1 (f1 /* boolean */) values ( 1=1 );

??? Ведь "1" записывает !

[Сергей Смирнов]

Лично я вижу (TSqlite3Dataset & TSQLite3Connection) как переведенные на другое API PostgreSQL-братья.

Это ещё и в их глюках разбираться?!
Вот ещё какой вопрос: что-то у меня SQLite неправильно сортирует русские буквы. Вроде как оно лечится с помощью sqlite3_create_collation. Так вот, кто-нибудь это делал?

[debi12345]

Лично я вижу (TSqlite3Dataset & TSQLite3Connection) как переведенные на другое API PostgreSQL-братья.

Это ещё и в их глюках разбираться?!

Пока все глюки выловлены - если взять PQCONNECTION.PP из ветки (2.1) . Во всяком случае, в DB-компонентах MSEgui пока все пучком, за Лазурус не знаю. Иначе бы и не предагал PostgreSQL за образец