Встроенная DB на Common Lisp

Почему бы не использовать очевидный sqlite? «Встраиваемая» БД всё равно же подразумевает сохранение на диск в виде файлов.

часть кода уже на Racket, часть будет на СL

А в чем смысл?

Какого плана БД требуется?

Если реляционная, то присоединяюсь к вышеотписавшимся.

Если что-то другое, то уточните, и присоединяюсь к вопросу alienclaster.

UPD: Я понимаю что оффтоп, но всё же интересно. Какие-то библиотеки есть только на Racket, какие-то только на CL? Начали на Racket но столкнулись с проблемами которых не должно быть в CL?

Был какой-то Elephant. Из БД в памяти, хранящей лисп-объекты, есть ap5, она однозадачная и достаточно тормозная. Зато красота. Да вообще по-моему их много, они зачастую реализованы с применением CLOS.

Реляции не требуется. Нужно хранить по сути плоские JSON’ы

Часть команды когда-то писало на CL. Им проще на нём. Я сейчас другую часть делаю на Racket, сервисы не связанные, обращение только по API

А есть ли сейчас жизнь в сообществе CL?

О, я смотрю, что Всеволод Дёмкин книгу написал: https://leanpub.com/progalgs

Нужно хранить по сути плоские JSON’ы

Т.е. по сути плоские alist. Вопрос, зачем для этого какие-то специальные выкрутасы? Тебе индексы нужны?

PicoLisp

Плохие воспоминания от пиколиспа.

А к БД откуда цепляться? Из CL?

А данные сложные/большие/разные? Может хеш табличку заюзать и всё?

Я слышал, что весеннее обострение связано с фазовыми переходами воды через ноль. Не знаю, насколько это правда. И мне сложно судить, бывает ли весеннее обострение в США, где другой климат, какая там сейчас погода и т.п.

Но трафик в подписках по CCL и LW, на которые я до сих пор подписан, за последнее время существенно активизировался.

Сам я в жизни CL сообщества не участвую, разве только перепостил вот это: http://lisper.ru/forum/thread/1391

Из известных мне лично лисперов в России ни один, насколько я знаю, по работе на лиспе сегодня не пишет.

Из известных мне лично лисперов в России ни один, насколько я знаю, по работе на лиспе сегодня не пишет.

Хм, но мне кажется, что кто-то все равно пишет.

Весной световой день увеличивается. А у больных шизофренией есть особенности, связанные с эпифизом, который регулирует суточные ритмы.

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

Да. Индексы желательно чтобы были. Нужно обеспечить быстрое чтение. Запись может быть медленной

Да. Из CL

Why?

Данные могут быть объемными. От 15 до 200 параметров на документ

А данные сложные/большие/разные? Может хеш табличку заюзать и всё?

Ты ему еще предложи все на сижке переписать и обычный struct MyStruct my_array[MY_MAX]; использовать, как сижники любят делать.

Разорванный Флакон

Весной световой день увеличивается. А у больных шизофренией есть особенности, связанные с эпифизом, который регулирует суточные ритмы.

В полнолуние.

Всё зависит от условий, если нужна локальность данных и нужно эти данные молотить по кругу адово на 100500 ядрах то да, предложу =) Но ему же просто хранить и иногда писать/читать. Так что нет, не предложу ибо посоветовали уже sqlite

нужно эти данные молотить по кругу адово на 100500 ядрах

Сижников хлебом не корми, дай только байтики помолотить, поперекладывать их из одного места в другое и обратно, пока остальные просто используют zero-cost абстракции в нормальных языках.

Так что нет, не предложу ибо посоветовали уже sqlite

Полностью согласен sqlite-0.25.0

Разорванный Флакон

По-моему, все виды Лиспа не нужны. А ввиду относительной малочисленности сообщества наверно и библиотек к ним мало, например, драйверов баз данных.

Но есть идея. В последнее время к популярным СУБД стали предоставляться REST API, что позволяет обращаться к ним из любого языка, лишь бы он поддерживал посылку и получение данных по сети. Может это Лисп? Тогда этот способ подойдёт.

Я помнил, что REST API есть для Oracle и PostgreSQL. Но они не слишком встраиваемые. Вот, маленькая СУБД SQLite. Часто используется как встраиваемая. Узнал, есть ли для неё REST API: делаю поиск в Google по словам SQLite REST API… да, есть.

например, драйверов баз данных

Достаточно. Во всяком случае, всё мейнстримное есть.

В последнее время к популярным СУБД стали предоставляться REST API

Давным давно есть odbc, в т.ч. в лиспах.

Но это не то. Товарищ спрашивает про нативную БД на лиспе. Таковых, готовых для продакшена, с открытым кодом, я не помню. Навелосипедить можно и даже не очень сложно, но надо ли? Я лично сомневаюсь в целесообразности этого.

По-моему, все виды Лиспа не нужны. А ввиду относительной малочисленности сообщества наверно и библиотек к ним мало, например, драйверов баз данных.

Смешно, но с Racket, например, у меня было меньше проблем с драйверами и библиотеками, чем в том же NodeJS (где всего много и всё полурабочее или работает не так как надо). Ну или мне просто уже приелся NodeJS на столько, что меня от него тошнит)

Но есть идея. В последнее время к популярным СУБД стали предоставляться REST API, что позволяет обращаться к ним из любого языка, лишь бы он поддерживал посылку и получение данных по сети. Может это Лисп? Тогда этот способ подойдёт

Может. Но хотелось работы с данными по принципу zero cost, а не через такие ухищрения. В подходе как у того же PicoLisp мы получаем по сути просто очень программируемую СУБД, которая способна очень быстро читать, но медленно писать (чтение в моём случае более быстрая процедура).Поэтому ограничение не существенное.

Я помнил, что REST API есть для Oracle и PostgreSQL. Но они не слишком встраиваемые. Вот, маленькая СУБД SQLite. Часто используется как встраиваемая. Узнал, есть ли для неё REST API: делаю поиск в Google по словам SQLite REST API… да, есть.

Вот опять с реляцией… Зачем она тут? В задачи 1 коллекция и ни одной реляции. Ради этого держать либо таблицу с овердофига столбцов, либо выстраивать связи в БД. Дичь.

Почему-то fork на разных компьютерах отрабатывал по разному. Так и не разобрался почему, прыгнул на guile.

Можно какой-нибудь биндинг для bdb заюзать. Вполне себе просто получится. И просто.

В BDB индекс придётся самому делать. :) Так что если документ, то, наверное, всё же, sqlite.

Ради этого держать либо таблицу с овердофига столбцов

Sqlite умеет в json.

Сама идея упростить проект выкинув не нужное абсолютно правильна. Но замена PicoLisp на Sqlite или что-то подобное ничуть не уменьшает зоопарк. Но всё это мелочи на фоне связки двух монстров CL+Racket для pet-проекта.

Почему бы не решить проблему более простым образом: выкинув CL+Racket+Sqlite и оставив один PicoLisp?

Почему бы не решить проблему более простым образом: выкинув CL+Racket+Sqlite и оставив один PicoLisp?

Common Lisp будет использоваться на очень узкой задаче, основная часть кода Racket. PicoLisp из команды никто не знает. Да и перспективы развития у PicoLisp выглядят очень туманно.

Перспективы развития очень просты: язык полностью стабилен и его развитие последние годы заключается в переносе на новые платформы и исправлении очень редких ошибок.

https://github.com/Wukix/LambdaLite

Ещё есть bknr-datastore и cl-prevalence

Есть не_встроенная. Грэм просто кидал секспами в файлы.