SQLite *

Здравствуй, уважаемый 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, другие же требуют нестандартного подхода. В данной статье я хочу рассказать историю о том, как можно с помощью исходников, рефлексии и трех кружек чая решить одну пренеприятнейшую проблему.

В данном посте описана система блокировок и поддержания атомарности, согласованности, изолированности и надежности (ACID) в SQLite, а также алгоритмы записи и чтения из файла базы.

В данном посте описаны внутренние таблицы SQLite: их строение и назначение.

В данном посте база SQLite будет рассмотрена в разрезе, вы можете найти информацию о строении файла базы данных, о представлении данных в памяти, а также информацию о структуре и файловом представлении В – дерева.

Уязвимость информации, хранимой в базах данных, является одной из самых распространенных проблем безопасности iOS приложений. Многие программы предлагают пользователю использовать пароль для доступа к данным — но в большинстве случаев это никаким образом не влияет на то, в каком виде хранится сама информация. Таким образом, к данным таких приложений, как менеджеры паролей, блокноты, органайзеры, трекеры финансов, может получить доступ практически любой посторонний, в руках у которого окажется ваше устройство.

Вступление

После некоторого перерыва в разработке моего приложения под Android, в течение которого в моей голове формировались все новые и новые идеи, как сделать его красивее и удобнее, в конце января я вновь уселся за разработку. За время размышлений подход к созданию приложения немного трансформировался, и посему до объектной модели я добрался только тройку недель назад. И почти сразу столкнулся с необходимостью доработки UCAOrm. Кому интересно узнать не только об уже внедренных нововведениях, но и о том, что еще только в процессе разработки —

Возвращение к истокам

Delphi XE5 я взял в руки по случаю конкурса «Осенняя Мобилизация». Идея (и возможность) писать под Андроид не на си-шарпе или яве, а на знакомом вдоль и поперёк паскале мне определённо понравилась. Расскажу тут о своих впечатления, проблемах, которые встретились, а также развенчаю некоторые «городские легенды».

Сначала результат, а потом разбор полетов. Допустим, вы создали запрос типа select [document].[id], [document].[name] from [SomeDocuments][document], но вместо ожидаемого

  id = 1
 name = d1

получаете

 document = 1
 document = d1

А теперь, если интересно будем разбираться.

В данной статье оценивается применение SQLite для PHP-проектов, рассматриваются особенности многопоточной работы и способы ускорения работы. «На десерт» — небольшое сравнение с другими СУБД (MySQL, PosgreSQL, MS SQL, MongoDB).

В буржунете есть интересный документ по оптимизации SQLite на платформе BlackBerry. Однако, идеи, которые в нем содержатся, вообще говоря, относятся к любой мобильной платформе. Мы решили развить этот список и создать эдакий эталонный текст в рунете с набором полезных, вводных советов для программирования SQLite под мобильными устройствами. Принимаем ваши предложения в комментариях.

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

Постигшие дзэн Пайтона считают, что должен быть один (и, желательно, только один) очевидный способ достигнуть желаемого.

А постигшие список модулей Node.js могут убедиться в том, что создатели этих модулей духовно ближе не к дзэн-буддистам, а к байхуистам — к поклонникам движения «Байхуа юньдун» (百花运动), провозглашённого Мао Цзэдуном в 1957 году по мотивам классического китайского стихотворения «пусть расцветают сто цветов, пусть соперничают сто школ», начинающегося словами «бай хуа» («百花», «сто цветов»). Иными словами, модули для Node.js предоставляют, как правило, несколько способов сделать одно и то же, и из них потребитель выбирает тот способ, который более всех пригоден ему.

Но почему не существует такого одного способа, который был бы пригоден для всех?

Ответ на этот вопрос я предлагаю рассмотреть на примере употребления базы данных SQLite.

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

Недавно появилась задача — встроить в приложение динамический поиск информации, то есть выдача должна генерироваться параллельно вводу пользователем символов. Вся информация хранится в SQLite базе данных. Все бы ничего, но в каждом слове выдачи искомые символы должны подсвечиваться.
Было принято волевое решение не использовать внешние библиотеки, а попробовать обойтись своими силами.