LINUX.ORG.RU

Объектная база данных для python

 ,


1

2

День добрый

Нужна база данных, умеющая сохранять объекты как они есть в базу, что-то вроде ZODB

Этот ZODB весьма хорош, для доступа различных процессов использовал сервер ZEO, но при попытках изменения одного и того же объекта разными процессами, возникает ConflictError, который непонятно как разрешать, а вся документация весьма неполная, зато полна битых ссылок на уточнения.

Есть какие либо варианты? Основные критерии: сохранение объектов как они есть (все SQL отпадают разом), изменение сохранённых объектов прямо в базе, возможность изменения всей базы из разных процессов

Смотрел в сторону MongoDB, но она оказалась документоориентированной, а перестраивать работу приложения под представление объектов в JSON формате - совсем не вариант

Основные критерии: сохранение объектов как они есть (все SQL отпадают разом).

Ась? А ты чего тогда хочешь, cloudpickle/dill с одновременным доступом?

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

Ну сложи их выхлоп в базу. Или на диск шалашиком и защити файлом блокировки. Или смилуйся и расскажи накой =D

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

Да я и так расскажу: я ленивый.

Сайт с списком серверов и их атрибутами. Заместо того, чтобы всё складировать через обычные бд, нашёл этот ZODB и, не парясь, написал классы, представляющие сервера и все их составляющие, и сохранял через него.

Надо сказать очень удобно - без вякого, просто работаем со всем содержимым как с обычными объектами. Но теперь появилась нужда менять объекты сторонними процессами - а оно конфликты выдаёт. Причём конфликты не из-за одновременной записи/незавершённой транзакции другого процесса, а просто потому, что этот объект принадлежит другому процессу, насколько я понял. Хотя вроде для маленьких объектов разобрался, как их менять, но вот как менять сложные объекты, или что я делаю не так - нет.

Ну и просто теперь думаю найти что-то такое же, но другое, более свежее с нормальной документацией.

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

Так на слух тебе обычная попсовая SQL СУБД и любой популярный ORM подойдут уже лучше. Но если одной попытки полениться и получить в итоге совсем не то тебе не хватило, то кто ж тебя остановит.

t184256 ★★★★★
()

Основные критерии: сохранение объектов как они есть (все SQL отпадают разом)

С чего бы? pickle и храни в вообще любой базе.

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

Как сложную структуру я туда засуну? Когда одно поле одной записи должно содержать неопределенное количество сложных объектов?

Architector
() автор топика

хотел предложить RethinkDB, но дочитал до твоих глупостей с JSON.. тебе виднее.

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

@Architector, слушай старших, дело говорят. Сначала мысленно начинаешь воспринимать строку (row) в таблице как объект, а колонки как атрибуты, затем берёшь SQLAlchemy и перестаёшь ощущать разницу. Потом, когда тебе понадобятся (а они понадобятся) возможности СУБД, они у тебя уже будут.

WitcherGeralt ★★
()

Этот ZODB весьма хорош, для доступа различных процессов использовал сервер ZEO, но при попытках изменения одного и того же объекта разными процессами, возникает ConflictError, который непонятно как разрешать, а вся документация весьма неполная, зато полна битых ссылок на уточнения

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

Объектная база данных для python (комментарий)

Сначала мысленно начинаешь воспринимать строку (row) в таблице как объект, а колонки как атрибуты, затем берёшь SQLAlchemy и перестаёшь ощущать разницу. Потом, когда тебе понадобятся (а они понадобятся) возможности СУБД, они у тебя уже будут.

Примерно так весь питон и «развивается».

byko3y ★★★★
()

SQL Mongo не вариант

А чо запикать, зажсонить/заблобить и положить в кей-валюе религия не позволяет что-ли? Зачем искать несовместимости в каких-то баззвордах, когда нужен просто инсерт и лукап с конкуренси.

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

Сначала мысленно начинаешь воспринимать строку (row) в таблице как объект, а колонки как атрибуты

Только атрибуты статически типизированные и типов очень мало. Это уже не совсем питон…

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

Так получается у меня атрибут объекта - это ячейка таблицы. А если у меня атрибут это список? Список объектов со своими атрибутами? Список объектов со своими атрибутами, которые могут быть также списками объектов?

У меня же сервер - это не IP:Port, а ещё список пользователей на нём, у каждого пользователя свои поля и т.д.

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

Да без проблем, совсем немного нормализации потребуется. В алхимии на атрибут можно повесить директиву orm.relationship и «бесплатно» получить загрузку отношений, или просто где-то использовать Array и JSON.

Для вставки только придётся пару лишних функций написать, не переломишься. Либо можно вообще взять что-то типа Flask-Retless и получить RESTful API полностью нахаляву, описав лишь модели.

Проблема не в РСУБД, а в том, что ты неосилятор.

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

В исходном сообщении про это ничего не было. Для этого в любом случае понадобится маппить объект на какую-то общую структуру типа json, а json умеют и уважающие себя реляционки.

slovazap ★★★★★
()

Как сложную структуру я туда засуну? Когда одно поле одной записи должно содержать неопределенное количество сложных объектов?

так json: { 'complex1': 'string' }, { 'complex2': { 'subtree': [1,2,3] } }, { 'complex3': [ { '1': 1 }, { '2': 3 } ] } - это ли не определенное количество сложных объектов?

дальше json.to_string() - в base64 - и в ЛЮБУЮ sql базу:

( id int primary key, server_name text, base64 text );

ключ, имя, бэйс64-строка жонса - там весь твой объект. Как назад в класс такое поднять конструктором, надо объяснять?

  • про лочку man fcntl
anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.