Если вы используете postgres, вы можете использовать разные с атрибутом fields, а затем использовать значения, чтобы получить нужные настройки,
ваш код будет эквивалентен:
feature.settings.distinct('name', 'active').values('name', 'active')
SQLite 3.x поддерживает это через функцию sqlite3_blob_write.
int sqlite3_blob_write(sqlite3_blob *, const void *z, int n, int iOffset)
Обратите внимание, что эта функция обеспечивается как часть API SQLite 3 C/C++. Необходимо будет программировать против этого непосредственно для использования его.
Если Вы используете некоторую другую высокоуровневую обертку, такую как Система. Данные. SQLite, в прошлый раз, когда я смотрел, у Вас не будет доступа к этой функции.
Это не непосредственно ответ на Ваш вопрос, но у меня есть некоторый опыт с помощью произвольного доступа для (больших) блобов в SQLite, и я отговариваю Вас от использования его, если Вы можете. Вот то, почему:
Блобы повреждают формат SQL-запроса полностью. Если Вашим данным блоба будет нужен какой-либо вид обработки, то этому, конечно, в какой-то момент будет нужна фильтрация. Безотносительно механизма Вы имеете в распоряжении для контакта с просачиванием SQL, будет бесполезно в этом отношении.
Контакт с двоичными блобами, перенесенными в базы данных, настроенные против двоичных данных в необработанных файлах, ограничивает Ваши опции. Вы не сможете случайным образом читать и запишете в данные одновременно из нескольких процессов, который возможен с файлами. Вы не можете использовать инструмент, который имеет дело с этими данными и обеспечивает только интерфейс файлового ввода-вывода. Вы не можете усечь или изменить размер блоба. Файлы просто намного более универсальны.
Может казаться удобным содержать все в одном файле, поскольку это упрощает резервное копирование и передачу, но боль работы с блобами просто не стоит того.
Таким образом, как Ваш адвокат, я советую Вам писать свои блобы как необработанные файлы к файловой системе и просто хранить ссылку на имя файла в Вашей базе данных. Если Ваши блобы являются довольно маленькими и гарантированы не вырасти, забудьте мой совет.
Я полностью согласен со всем, что сказал paniq. Использование больших двоичных объектов значительно ограничивает ваши возможности.
Если вы используете System.Data.SQLite, у вас не будет реальной поддержки больших двоичных объектов. Вот почему я написал свой собственный класс для их обработки. Вы можете найти код здесь: Пример кода BLOB
Обратите внимание, что SQLite имеет несколько потенциальных ловушек для тех, кто осмеливается работать с BLOB. Одна из основных проблем заключается в том, что SQLite загружает все BLOB-поля в память, прежде чем вы сможете даже проверить их длину. Так что ожидайте большого объема памяти, если у вас есть большие BLOB-поля ...