SQLite *

Всем привет. Пишу на Хабре впервые, не судите строго. Хочу поделиться своим опытом поиска универсальной SQLite ORM библиотеки на С++ и моей новой разработкой собственной библиотеки для работы с SQLite на C++ sqlite_orm.

Когда я искал ORM'ку я отталкивался от нескольких ключевых пунктов:

• библиотека должна иметь как CRUD, так и не CRUD
• должны быть гибкие условия WHERE, а не тупо WHERE id = ?
• должен быть функционал миграций (синхронизации схемы) на случай обновлений приложения
• фичи вроде ORDER BY и LIMIT тоже должны быть
• сериализация классов не должна быть написана в своих классах. Это очень важный пункт для меня с тех пор, как я познакомился с Java и с Android-разработкой в частности. Android-разработчики стараются придерживаться принципа единственной ответственной (single responsibility principle), что очень важно если приложение собрано из разной кучи библиотек и модулей, которые могут меняться с течением времени. И поэтому самая популярная на github SQLite ORM'ка на С++ hiberlite меня не устроила способом сериализации — класс модели должен иметь статичную функцию serialize с кодом непосредственной сериализации. Я искал такой модуль, от которого бы не зависел код моей модели данных. Ведь у меня может быть несколько сериализаторов (JSON, XML, SQLite), и по-хорошему каждый должен прилагаться к модели данных, но никак ее не менять, а иначе получится каша в коде модели.
  

Ранее мы уже публиковали статью о том, как генерировать фиктивные данные при помощи Mimesis — библиотеки для языка программирования Python. Статья, которую вы читаете является продолжением предыдущей, потому мы не будем приводить основ работы с библиотекой. Если вы пропустили статью, поленились прочитать или просто не захотели, то, вероятно, захотите сейчас, ибо эта статья предполагает, что читатель уже знаком с основами библиотеки. В этой части статьи мы будем говорить о best practice, расскажем о нескольких, на наш взгляд, полезных особенностях библиотеки.

Данная статья написана по мотивам – мотивам разработки мобильного приложения, недавно вышедшего на платформах iOS и Android. Это событие можно было бы назвать заурядным и мало кому интересным, если бы не одно большое и несколько незначительных «но»: вся разработка (включая сервер) велась на Delphi, а в качестве СУБД, как ни странно, задействована совсем не SQLite. Автор, безусловно, понимает, что на текущий момент уже существуют мобильные Delphi-приложения, включая доступные в официальных магазинах, однако не наблюдает обилия русскоязычных публикаций, призванных, как минимум, предостеречь читателей от ошибок, сделанных разработчиком таких проектов. Написанное же здесь преследует цель помочь тем, кто сейчас выбирает СУБД для своего творения, либо уже остановился на каком-то варианте, но желает убедиться в правильности своего решения.

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

Приветствую, уважаемое сообщество!
Забегая вперед прошу прощения у тех, кто ожидает новизны или революционных идей. Их тут нет. Но есть вполне хорошая прикладная система.

Системы поддержки принятия решений сейчас набирают обороты. Причем я не буду особо останавливаться на перечислении способов реализации. Оговорюсь только об основных свойствах. Я бы очень упрощенно и обобщенно назвал эти системы вероятностными. То есть они выдают рекомендации с известной долей вероятности используя накопленную и проанализированную статистику. Не скажу что это плохо. Тема BigData и Machine learning нынче в тренде. Так же эти системы работают по принципу черного ящика. Поэтому проверить достоверность работы заложенной модели не всегда можно выявить.

Казалось бы, каждый, кто осваивает ардуино, первым делом конструирует или повторяет прибор для измерения температуры и(или) прочих параметров окружающей среды. Только большинство подобных конструкций, к сожалению, мало применимы в домашнем хозяйстве — в качестве тренировки сгодится, а пользы нет. Попробуем исправить эту недоработку. В статье расскажу о создании комплекса для измерения и хранения любых данных на примере сбора показаний датчиков температуры, влажности воздуха и атмосферного давления. Начну с требований к прибору и описания протокола обмена, закончу web-службой для получения данных из БД. Подробных выкладок и пошаговых руководств не будет, но будет немного теории и много кода.

Сразу же предупрежу о велосипедности выдаемого здесь на обозрение. Если прочтение заголовка вызывает лишь с трудом подавляемый возглас «Твою мать, только не новый таксон ORM!», то лучше наверное воздержаться от дальнейшего чтения, дабы не повышать уровень агрессии в космологическом бульоне, в котором мы плаваем. Виной появлению данной статьи явилось то, что в кои-то веки выдался у меня отпуск, в течение которого решил я попробовать себя на поприще написания блогопостов по околохабровской тематике, и предлагаемая тема мне показалась вполне для этого подходящей. Кроме того, здесь я надесь получить конструктивную критику, и возможно понять чего же еще с этим можно сделать этакого интересного. В конце будет ссылка на github-репозиторий, в котором можно посмотреть код.

Популярная в Android-среде СУБД SQLite позволяет организовывать удобные хранилища данных, её возможностей достаточно для многих приложений, но не для тех, что работают с информацией, которую надо защищать.

Если ваш проект из этой серии, скажем, вы создаёте программу для хранения паролей и пользуетесь SQLite, дополнительные меры безопасности будут очень кстати. Одна из таких мер – шифрование.

Столкнувшись с задачей подключить SQLLite к своему мобильному приложению iOS через FMDB, я не нашел ни одного актуального гайда на русском языке. И тем более для Swift. В этой статье я постараюсь этого исправить.

В этом гайде будут использоваться файлы с objective-c, поэтому не надо ждать порта FMDB на Swift.

Скачать FMDB можно тут.

В FMDB три main class:

FMDatabase — представляет данных SQLite. Используется для выполнения SQL-операторов.
FMResultSet — представляет результаты выполнения запроса по FMDatabase.
FMDatabaseQueue — если вы хотите, чтобы выполнялись запросы и обновления на несколько потоков, можно использовать этот класс. Пример в 8 пункте.

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

if (![db open]) {
    [db release];
    return;
}

Шаги:

Имеется типична ситуация:

• кем-то написанное приложение на Qt;
• пользователи жалуются, что программа во время работы жрем много CPU;
• профилировщик и strace указывают на то, что происходит насилование базы.

В такой ситуации хочется посмотреть что за запросы, их количество, время выполнения. Если в PostgreSQL есть pg_stat_statements и pgBadger, то для SQLite пришлось написать свой самокат. Самокат представляет из себя вызов sqlite3_profile для каждого соединения, запись полученной информации в журнал.

На сегодняшний день две мои самые любимые темы — SQLite и key-value базы данных. И в этот раз я пишу сразу про обе: этот пост посвящён Python-обёртке для используемого в SQLite 4 key-value хранилища на основе LSM.

Я не слишком внимательно отслеживаю релизы SQLite, но версия 3.8.11 привлекла моё внимание, поскольку в её описании заявлено серьёзное увеличение производительности по сравнению с 3.8.0. В сопроводительной информации я наткнулся на упоминание о новом экспериментальном расширении для полнотекстового поиска (о котором писал когда-то), и потому мне стало интересно, какая складывается ситуация с SQLite 4.

Изучив доступную информацию, я обратил внимание, что одной из задач разработчиков было обеспечить в новых версиях интерфейс для подключаемых движков баз данных. На момент написания этого поста в SQLite 4 уже было два встроенных бэкенда, один из которых — key-value хранилище на основе LSM. В последние пару месяцев мне доводилось поиграться с Cython, пока я писал Python-обёртку для встроенных k-v хранилищ UnQLite и Vedis. И я подумал, что было бы неплохо применить Cython для создания интерфейса движка БД на основе LSM, используемого в SQLite 4.

Разобравшись с исходным кодом SQLite 4 и крохотным заголовочным файлом LSM, я написал python-lsm-db (документация).

SQLite это кроссплатформенный (Windows, iOS, Android, Python, Mono и др.) движок базы данных с открытым исходным кодом. Он поддерживает множественные таблицы, индексы, триггеры и представления.
Поддерживаются ACID транзакции (Atomicity/Атомарность, Consistency/Согласованность, Isolation/Изолированность, Durability/Надежность).
SQLitePCL – это библиотека Portable Class Library с открытым исходным кодом, доступным по адресу https://sqlitepcl.codeplex.com/, которая позволяет работать с базами SQLite единым образом и в .Net приложениях и в WP, Windows Store, UAP, а также Android/iOS (с помощью Xamarin). Другими словами, это обертка/wrapper библиотеки C, которая упрощает разработку и экономит время. Обертка довольно новая. Ранее для приложений .Net и Windows Store можно было использовать обертку sqlite-net.

Как и во многих других приложениях, нам в мобильном ICQ приходится хранить достаточно много информации: сообщения, контакты и тому подобное. Когда количество запросов к этим данным достигает какого-то критического значения, приложение начинает тормозить. Долгий запуск, медленное открытие чата, медленная отправка сообщений, постоянные спиннеры — все это жутко напрягает. Чаще всего причиной тормозов является неудачная работа с данными. В статье я хочу поделиться нашим опытом рефакторинга структуры данных, оптимизации запросов и некоторыми удобными приемами для миграции.

Несколько слов об исходной задаче. Основная сущность у нас — профиль ICQ, у которого есть список контактов, а у тех есть сообщения. Наше приложение существует уже много лет, разрабатывалось разными людьми с разными подходами, номер версии основной БД уверенно приближался к 30. Кроме того, количество фич в продукте невозможно предсказать заранее, это тоже повлияло на архитектуру. В общем, модель данных изначально была примерно такой:

На C# я пишу редко, и в основном все наши приложения и сервисы подключаются к источнику данных, используя MSSQL сервер или службы баз данных. И вот настало время написать приложение, используя не сервер, а локальную БД. Немного погуглив, я внезапно выбрал SQLite.

Предисловие

У всех наших заказчиков были требования к коду:

• установленное именование переменных;
• группировка кода (конструкторы, переменные, методы, события...);
• табы и форматирование (каралось смертной казнью);
• за самописные SQL запросы разработчик удалялся из команды.

Исходя из вышеперечисленного, для баз данных конечно же были использованы классы LINQ to SQL, связанные с реляционными объектами.

Здравствуй, уважаемый All!

Хочу рассказать о небольшой библиотеке для работы с SQLite в Windows Phone 8.0 Silverlight, Windows Phone 8.1, Windows 8.1 а сейчас еще и для Windows 10 UAP. Библиотеке уже больше года и т.к. проблем с ней за все время не возникло, то, я считаю, о ней можно рассказать другим.

Зачем все это?
Библиотека в рамках Windows Phone 8.0 Silverlight, Windows Phone 8.1, Windows 8.1 просуществовала больше года. Спрашивается: почему именно сейчас я решил о ней рассказать? Дело в том, что сейчас пора портировать свои приложения для Windows 10, а официального SQLite SDK пока нет.
Вот здесь есть SDK для Windows Phone 8, Windows Phone 8.1, Windows 8 и Windows 8.1. Но не для Windows 10.
И скорее всего не будет до выхода Windows 10. Поэтому есть смысл посмотреть на эту библиотеку.

Поехали
Библиотека называется SQLite.WinRT.

SELECT * WHERE LOWER_FNC(name) like '%" + filterText + "%'"

При разработке Android приложения столкнулся с проблемой в запросе SQLite фильтра с русскими буквами. Для английской локализации проблем нет. Для других интернациональных раскладок некорректно обрабатывались заглавные буквы в запросе.
Немного разобравшись я наткнулся на следующее описание:

(18) Case-insensitive matching of Unicode characters does not work.

The default configuration of SQLite only supports case-insensitive comparisons of ASCII characters. The reason for this is that doing full Unicode case-insensitive comparisons and case conversions requires tables and logic that would nearly double the size of the SQLite library. The SQLite developers reason that any application that needs full Unicode case support probably already has the necessary tables and functions and so SQLite should not take up space to duplicate this ability.

Instead of providing full Unicode case support by default, SQLite provides the ability to link against external Unicode comparison and conversion routines.

Вероятно текущая реализация SQLite Android и есть

only supports case-insensitive comparisons of ASCII characters

Видел решение через CursorWrapper но решил все таки собрать свою версию SQLite и использовать addCustomFunction

Что из этого получилось читайте под катом

Недавно мы опубликовали серию статей, посвящённых разработке приложений в FireMonkey. Тогда мы описали ключевые моменты построения приложения, в том числе создание базы данных, подключение данных с помощью технологии LiveBinding, развёртывание приложения на мобильной платформе. Однако, детально рассматривать ньюансы создания мобильных приложений мы не стали. Во многом это связано с тем, что сам процесс мобильной разработки в Delphi эволюционирует от версии к версии. В частности, в последней XE7 на сегодняшний день версии Delphi, был представлен новый дизайнер форм FireUI Multi-Device Designer. В данной статье с помощью небольшого примера мы рассмотрим, что же из себя представляет FireUI и каким образом с его появлением изменилась методология разработки.

Для шифрования в SQLite были найдены следующие возможные решения:

• SEE — официальная реализация.
• wxSQLite — c++ wxWidgets обертка для шифрования SQLite.
• SQLCipher — использует в реализации openSSL.
• SQLiteCrypt — модифицированная реализация API.
• botansqlite3 — шифрующий кодек для SQLite3 использующий библиотеку botan.
• SQLiteCrypto — java API для Android, использует AES-256 и SHA-256.
• QtCipherSqlitePlugin — SQL плагин для Qt с поддержкой шифрования.

Из рассмотренных решений SEE, SQLiteCrypt and SQLiteCrypto требуют приобретения лицензии. SQLCipher доступен в версии Community Edition, но требует libcrypto.

Наиболее интересным решением из представленного списка, на мой взгляд, является QtCipherSqlitePlugin.
Плагин шифрует «на лету» и полностью интегрирован в API Qt.

В этой статье рассматривается вариант установки Redmine с базой данных SQlite3 на Windows и запуск его как сервиса. Все необходимые компоненты для установки приведены в статье. Для тестирования была установлена виртуальная машина с «голым» Windows 7 без пакетов обновления, без дополнительного ПО и произведена пошаговая установка по инструкции в статье.

Ответ на вопрос: «Сколько требует ресурса так установленная Redmine?»

ОЗУ: Процесс Redmine использует 2 МБ оперативной памяти, а интерпретатор Ruby «ест» 170 МБ оперативной памяти.
ЖД: Установленный «пустой» Redmine с остальным ПО занимает ~500 МБ жесткого диска.

Купил я как-то Lenovo A706 — и был я им доволен, и доволен весьма. Нашлась, правда, пара связанных с самостоятельностью экрана глючков, хотя в целом — вполне годный аппарат. Но однажды, в одну темную-темную ночь на даче приключилась с ним беда. Лежал он себе и заряжался. Перед этим пропадал свет, и я специально на ночь отключил передачу данных, чтобы сберечь батарейку, если свет опять погаснет. И оставил я его лежать мордой вниз…

Работа с детищем Xamarin интересна и полна сюрпризов, как в хорошем смысле слова, так и в плохом. Одни проблемы решаются при помощи гугла и StackOverflow, другие же требуют нестандартного подхода. В данной статье я хочу рассказать историю о том, как можно с помощью исходников, рефлексии и трех кружек чая решить одну пренеприятнейшую проблему.