LINUX.ORG.RU

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

 , , ,


1

6

Комрады, всех приветствую. Есть ли встраиваемая БД для Common Lisp? Делаем небольшой pet-проект, часть кода уже на Racket, часть будет на СL. Для сервисов, где нужна не большая БД не хочется тащить ещё и PicoLisp. Посему вопрос.

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

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

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

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

Gentooshnik ★★★ ()
Последнее исправление: Gentooshnik (всего исправлений: 1)

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

den73 ★★★★★ ()
Ответ на: комментарий от dave

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

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

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

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

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

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

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

dave ★★★★★ ()
Ответ на: комментарий от Fast_Sloth

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

den73 ★★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

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

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

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

anonymous ()
Ответ на: комментарий от Fast_Sloth

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

LINUX-ORG-RU ()
Ответ на: комментарий от LINUX-ORG-RU

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

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

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

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

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

anonymous ()

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

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

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

Partisan ★★★ ()
Ответ на: комментарий от Partisan

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

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от Partisan

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

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

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

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

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

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

silver-bullet-bfg ★★ ()

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

silver-bullet-bfg ★★ ()
Последнее исправление: silver-bullet-bfg (всего исправлений: 1)
Ответ на: комментарий от silver-bullet-bfg

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

anonymous ()