Сергей Смирнов писал(а):
Это ещё и в их глюках разбираться?!
debi12345 писал(а):Лично я вижу (TSqlite3Dataset & TSQLite3Connection) как переведенные на другое API PostgreSQL-братья.
Это ещё и в их глюках разбираться?!
Пока все глюки выловлены - если взять PQCONNECTION.PP из ветки (2.1) . Во всяком случае, в DB-компонентах MSEgui пока все пучком, за Лазурус не знаю. Иначе бы и не предагал PostgreSQL за образец
Статистика: Добавлено debi12345 — 21.09.2006 22:11:33
]]>
debi12345 писал(а):Лично я вижу (TSqlite3Dataset & TSQLite3Connection) как переведенные на другое API PostgreSQL-братья.
Это ещё и в их глюках разбираться?! Вот ещё какой вопрос: что-то у меня SQLite неправильно сортирует русские буквы. Вроде как оно лечится с помощью sqlite3_create_collation. Так вот, кто-нибудь это делал?
Статистика: Добавлено Сергей Смирнов — 21.09.2006 17:09:22
]]>
Есть еще проблема с Boolean-полями - в них True=1, поэтому сравнение с 't'/'f' дает левые результат
Вообще-то BOOLEAN-поля принимают и "=1" и "='t'", причем и сохраняет в таком же виде, и в операциях использует. По идее, для соместимости с SQL-диалектом - нужно остановиться на 't/f' варианте, и контроллировать ( и конвертировать ) как раз через процедуры адаптации в "tsqlite3connection.pp". Но как быть с присвоениями, делаемыми в SQL-запросах, минуя FPC-продедуры, типа :
insert into t1 (f1 /* boolean */) values ( 1=1 );
??? Ведь "1" записывает !
Статистика: Добавлено debi12345 — 20.09.2006 22:39:18
]]>
то бишь прописать код конверсии - LoadFields etc.
Надо будет глянуть... хотя, кажись, ничего там делать не надо вообще.
Для Date[Time] и Boolean потребуется 100% ( они сохраняются нормально, учавствуют в операциях тоже - но представляются нестандартно ). Есть еще проблема с Boolean-полями - в них True=1, поэтому сравнение с 't'/'f' дает левые результаты.
Лично я вижу (TSqlite3Dataset & TSQLite3Connection) как переведенные на другое API PostgreSQL-братья.
Статистика: Добавлено debi12345 — 20.09.2006 16:33:14
]]>
debi12345 писал(а):Но чтобы это пахало, нужно опять-таки :
то бишь прописать код конверсии - LoadFields etc.
Надо будет глянуть... хотя, кажись, ничего там делать не надо вообще.А саму конверсию по ЯВНО указанному типу - перепоручить TSQLite3Connection - аналогично TPQConnection, где используется API самого DB-баскенда.
то бишь прописать код конверсии - LoadFields etc.
Вот это уже интересно. У меня 3.3.7 - там всё плохо.debi12345 писал(а):Кстати, в SQLite3 последних сборок много чего доработано - кажется, и по части типов данных из пустых запросов в том числе. Проект ( SQLite3 )очень быстро прогрессирует.
Эээ... ну я ничем таким не пользовался, ничего не понял, но было интересноdebi12345 писал(а):Кому как. Во-первых, даже сейчас - проблема возникает только на некоторых типах вроде даты и булевых.
Во-вторых, лично я создаю persistent-поля очень часто - для настройки ProviderFlags, для доступа к удобному сервису вроде AsSQL ( значение в виде, готовом для конкатенации с SQL.Text - в MSEgui ), для доступа к ним в DesignTime, да и сам доступ к ним быстрее - сразу по адресу, вместо перебора по fieldbyname('fname'), что весьма заметно при большом кол-ве записей.
Статистика: Добавлено Сергей Смирнов — 20.09.2006 16:13:25
]]>
Сергей Смирнов писал(а):Редактор полей (FieldDefs) является частью инфраструктуры стандартного доступа к данным как в Дельфи, так и в Лазаре. Я не понимаю, как автору существующего SQLite3 датасета удалось это дело прибить.
Но чтобы это пахало, нужно опять-таки :
А саму конверсию по ЯВНО указанному типу - перепоручить TSQLite3Connection - аналогично TPQConnection, где используется API самого DB-баскенда.
то бишь прописать код конверсии - LoadFields etc.
Кстати, в SQLite3 последних сборок много чего доработано - кажется, и по части типов данных из пустых запросов в том числе. Проект ( SQLite3 )очень быстро прогрессирует.
Однако создавать каждый раз список полей - довольно геморно. Надо бы что-нибудь придумать.
Кому как. Во-первых, даже сейчас - проблема возникает только на некоторых типах вроде даты и булевых.
Во-вторых, лично я создаю persistent-поля очень часто - для настройки ProviderFlags, для доступа к удобному сервису вроде AsSQL ( значение в виде, готовом для конкатенации с SQL.Text - в MSEgui ), для доступа к ним в DesignTime, да и сам доступ к ним быстрее - сразу по адресу, вместо перебора по fieldbyname('fname'), что весьма заметно при большом кол-ве записей.
Статистика: Добавлено debi12345 — 20.09.2006 15:47:36
]]>
debi12345 писал(а):
Это неизбежно, в том числе и в Дельфи так было.Собственно, а чего там переводить? Редактор полей (FieldDefs) является частью инфраструктуры стандартного доступа к данным как в Дельфи, так и в Лазаре. Я не понимаю, как автору существующего SQLite3 датасета удалось это дело прибить. Однако создавать каждый раз список полей - довольно геморно. Надо бы что-нибудь придумать.Сергей Смирнов писал(а):Именно поэтому и говорю - нужно перевести SQLite3 на SQLDB. Потому что "там" можно обойти ограничение на автораспознавание типа полей, так как типом данных можно управлять через явное указание типа, работая с persistent-полями ( ftBoolen = ftInteger, etc ). А саму конверсию по ЯВНО указанному типу - перепоручить TSQLite3Connection - аналогично TPQConnection, где используется API самого DB-баскенда.
debi12345 писал(а):Кстати, сейчас такая же петрушка и с параметрами запросов у всех прочих DB-баскендов, и ничего - живем, опять-таки явно указывая типы данных запрашивамых параметров, или устанавливая их значения как "{parameter}.as{type}:= {value}".
Статистика: Добавлено Сергей Смирнов — 20.09.2006 12:34:21
]]>
Сергей Смирнов писал(а):Что до странностей, то я имел ввиду несколько другое. SQLite реализует очень странную типизацию данных: не на уровне метаданных (в смысле типов полей), а на уровне хранения, причём в одном поле могут спокойно соседствовать данные разных типов. Особенно сильно это влияет на данные типа даты. Кроме того нет никакой возможности получить тип поля в запросе, если оно не является простой ссылкой на поле таблицы. Например, получить тип вычисляемого поля запроса - в частности любой групповой функции - невозможно до считывания первой строки данных (а её может и не быть) и даже после этого определить тип точно всё равно нельзя, если это, скажем, дата/время. Вот такие трудности. А места вызова обработчиков событий по сравнению с этим - просто пустяки.
Именно поэтому и говорю - нужно перевести SQLite3 на SQLDB. Потому что "там" можно обойти ограничение на автораспознавание типа полей, так как типом данных можно управлять через явное указание типа, работая с persistent-полями ( ftBoolen = ftInteger, etc ). А саму конверсию по ЯВНО указанному типу - перепоручить TSQLite3Connection - аналогично TPQConnection, где используется API самого DB-баскенда.
Кстати, сейчас такая же петрушка и с параметрами запросов у всех прочих DB-баскендов, и ничего - живем, опять-таки явно указывая типы данных запрашивамых параметров, или устанавливая их значения как "{parameter}.as{type}:= {value}".
Статистика: Добавлено debi12345 — 20.09.2006 11:34:31
]]>
debi12345 писал(а):Вопрос уже поднимался - по части FreePascal SQLDB. Не надо с нуля. А надо перевести его на чистый SQL - то бишь реализовать интерфейс по типу PostgreSQL ( взять за прототип PQCONNECTION.PP ). Тогда и странности ( в основном места вызова обработчиков событий ) исчезнут.
Надо - не надо -- это ещё надо разбираться. В текущей реализации пока есть некоторые недоработки, в том числе и довольно глобальные. Можно ли их устранить не переделывая всё с нуля -- большой вопрос. Собственно, сам автор пока толком не знает.
Что до странностей, то я имел ввиду несколько другое. SQLite реализует очень странную типизацию данных: не на уровне метаданных (в смысле типов полей), а на уровне хранения, причём в одном поле могут спокойно соседствовать данные разных типов. Особенно сильно это влияет на данные типа даты. Кроме того нет никакой возможности получить тип поля в запросе, если оно не является простой ссылкой на поле таблицы. Например, получить тип вычисляемого поля запроса - в частности любой групповой функции - невозможно до считывания первой строки данных (а её может и не быть) и даже после этого определить тип точно всё равно нельзя, если это, скажем, дата/время. Вот такие трудности. А места вызова обработчиков событий по сравнению с этим - просто пустяки.
Статистика: Добавлено Сергей Смирнов — 20.09.2006 10:16:01
]]>
Однако надо на чём-то отработать технологию. И тут мы переходим к первой части темы. Чем хорош SQLite: он удобен, быстр и имеет очень простой и понятный API, в отличие, скажем, от FireBird/Interbase. Его популярность очень высока, по крайней мере, за границей.
...
Отсюда вопрос: а у нас этот самый SQLite кому-нибудь интересен? Кто-нибудь рассматривает его как движок БД для приложений локального масштаба?
...
Отсюда вопрос: а у нас этот самый SQLite кому-нибудь интересен? Кто-нибудь рассматривает его как движок БД для приложений локального масштаба?
Очень хороший и компактный движок, с поддержкой триггеров, индексов и юникода, нереально компактный ( одна DLL размером 230 К ), и невероятно быстрый.
Есть смысл разбираться с его, так мягко скажем, особенностями и дорабатывать существующий компонент для Lazarus (либо делать новый "с нуля")?
Вопрос уже поднимался - по части FreePascal SQLDB. Не надо с нуля. А надо перевести его на чистый SQL - то бишь реализовать интерфейс по типу PostgreSQL ( взять за прототип PQCONNECTION.PP ). Тогда и странности ( в основном места вызова обработчиков событий ) исчезнут.
Статистика: Добавлено debi12345 — 20.09.2006 08:17:21
]]>
Yogrik писал(а):Я даже готов помоч, чем смогу...
Но могу не многое, всеж студент как ни как...
Ну и сами понимаете с временем тоже не ахти....
Но всеже помочь готов...!!!!
Это хорошо, спасибо! Ничего слишком уж серьёзного делать, я думаю, не придётся. Там толпе народу просто делать нечего. Может быть потестить что-нибудь, пообсуждать, поделиться опытом использования SQLite, подумать, как обойти некоторые его странные фичи, а может даже использовать их во благо. Моральная поддержка тоже приветствуется Но могу не многое, всеж студент как ни как...
Ну и сами понимаете с временем тоже не ахти....
Но всеже помочь готов...!!!!
Статистика: Добавлено Сергей Смирнов — 19.09.2006 23:14:41
]]>
Да, есть люди которые использую sqlite для локальных
приложений...
Я даже готов помоч, чем смогу...
Но могу не многое, всеж студент как ни как...
Ну и сами понимаете с временем тоже не ахти....
Но всеже помочь готов...!!!!
Статистика: Добавлено Yogrik — 19.09.2006 23:03:43
]]>
Так вот. Проблема имеет место быть и начнёт решаться только после релиза Lazarus 1.0, который все и так уже устали ждать. В чисто практической плоскости это означает, что ждать милостей от природы (в смысле - от разработчиков) не приходится. Значит, нужна какая-то подпорка, которая позволила бы хотя бы частично снять проблему.
Единственным вариантом мне видится организация чего-то вроде пула соединений с базой данных (БД) - это снимает основную проблему с организацией централизованного подключения к БД. Реализовать это не очень сложно, хотя почему-то никто пока ничего похожего не сделал.
Однако надо на чём-то отработать технологию. И тут мы переходим к первой части темы. Чем хорош SQLite: он удобен, быстр и имеет очень простой и понятный API, в отличие, скажем, от FireBird/Interbase. Его популярность очень высока, по крайней мере, за границей.
Отсюда вопрос: а у нас этот самый SQLite кому-нибудь интересен? Кто-нибудь рассматривает его как движок БД для приложений локального масштаба? Есть смысл разбираться с его, так мягко скажем, особенностями и дорабатывать существующий компонент для Lazarus (либо делать новый "с нуля")?
Статистика: Добавлено Сергей Смирнов — 19.09.2006 22:54:02
]]>