ООDB на основе Pharo

… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,

Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,

Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,

Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

2 декабря 2014 г., 17:33 пользователь Nikolay Kleptsov <[hidden email]> написал:

БД MongoDb

Все таки Монго не объектная БД. Есть большая разница между документо-ориентированными и объектными БД. И, на мой взгляд, к NoSQL-базам не относят OODB. По крайней мере, ни в каких статьях по NoSQL я не видел упоминание OODB.

Главное отличие NoSQL от OODB - как они смотрят на взаимосвязи между объектами. Например, в Монго, если у вас один документ ссылается на другой, при удалении последнего в оригинальном документе останется невалидная ссылка. В объектной базе такое невозможно. Если вы удалите объект из некоторой коллекции-реестра, он никуда не денется из других объектов, которые на него ссылаются.
Я бы сказал, суть OODB именно в том, что данные в них организованы в виде объектов как в обычной объектной программе. То, что я видел среди NoSQL, таким свойством не обладает (MongoDB точно).

Среди OODB сильно выделяется Gemstone. Это уже не "тупое" хранилище данных, а полноценный смолтолк. Можно его воспринимать как многопользовательский имидж с транзакционной памятью. Сохранение имиджа в нем является коммитом транзакции (Smalltalk commitChanges). Кстати, на жемстоуне работают огромные коммерческие системы, в которых живут триллионы объектов (сотни терабайтов).

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Если не по типу жемстоуна, а просто как хранилище, то такое уже есть: Magma. Возможно, сейчас она не слишком дружит с фарой , но, думаю, портировать со сквика не такая большая проблема.

2 декабря 2014 г., 16:04 пользователь Dennis Schetinin <[hidden email]> написал:

… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,

Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если честно.

Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo превращала бы его в объектную базу данных со всеми фишками (ACID, пользователи) с максимально "прозрачностью" — чтобы написанное без БД приложение при загрузки этой библиотеки "автоматически" (без изменения кода) получало бы все эти вкусности… 

Что этому с технической т.з. мешает?

--

Best regards,

Dennis Schetinin

2 декабря 2014 г., 19:54 пользователь Denis Kudriashov <[hidden email]> написал:

Если не по типу жемстоуна, а просто как хранилище, то такое уже есть: Magma. Возможно, сейчас она не слишком дружит с фарой , но, думаю, портировать со сквика не такая большая проблема.

2 декабря 2014 г., 16:04 пользователь Dennis Schetinin <[hidden email]> написал:

… Раз пошла такая пьянка, подниму-ка и я один вопрос.

Можно ли на основе Pharo сделать нормальную объектную базу — по типу GemStone? И, если да, что для этого надо?

…И маленький со-вопросик: а какие еще ОБД реально существуют? Гуглить и википедировать я умею, поэтому вопрос именно про реальность: может, кто-то сталкивался на практике? Насколько с ними все хорошо/плохо?

--

Best regards,

Dennis Schetinin

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

2 декабря 2014 г., 19:34 пользователь Dennis Schetinin <[hidden email]> написал:

Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если честно.

Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo превращала бы его в объектную базу данных со всеми фишками (ACID, пользователи) с максимально "прозрачностью" — чтобы написанное без БД приложение при загрузки этой библиотеки "автоматически" (без изменения кода) получало бы все эти вкусности… 

Что этому с технической т.з. мешает?

Здесь виртуалка должна быть специальная. Образ должен грузится в разделяемую виртуальную память и много чего из этого следует.

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

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Ограниченость бесплатной версии Gemstone весьма относительная.
Бесплатная версия прекрасно используется в продакшн (в виде native
Seaside in Gemstone). Когда люди выходят за пределы ограничений
бесплатной версии, как правило  это уже реальный продукт, который
зарабатывает реальные деньги, люди сами готовы заплатить, чтобы иметь
реальную поддержку. Сделать что-то подобное конечно же можно, при
соотвественном вложении средств и людских ресурсов, но надо смотреть
на вещи реалистично. Не зря подозреваю Gemstone уже 30+ лет
оттачивают. Денис упоминал Магма http://wiki.squeak.org/squeak/2665
она конечно не без влияния Gemstone создавалось. Правда последнее что
я видел, работает вроде только с Pharo 1.4 может быть есть смысл
озачиться и подтянуть, а не изобретать новое, если так важен
opensource.

2014-12-02 9:26 GMT-08:00 Denis Kudriashov <[hidden email]>:

>
> 2 декабря 2014 г., 19:34 пользователь Dennis Schetinin <[hidden email]>
> написал:
>>
>> Я именно про GemStone, разумеется. Других настоящих ОБД я и не знаю, если
>> честно.
>>
>> Речь про то, чтобы сделать такой фреймворк, загрузка которого в Pharo
>> превращала бы его в объектную базу данных со всеми фишками (ACID,
>> пользователи) с максимально "прозрачностью" — чтобы написанное без БД
>> приложение при загрузки этой библиотеки "автоматически" (без изменения кода)
>> получало бы все эти вкусности…
>>
>> Что этому с технической т.з. мешает?
>
>
> Здесь виртуалка должна быть специальная. Образ должен грузится в разделяемую
> виртуальную память и много чего из этого следует.
> Такое наверно может быть возможно только в системах типа BeeSmalltalk или
> Mist. В них абсолютно все написано на смолотоке и изменяемо динамически,
> включая GC, JIT и так далее, и различные реализации этих компонент могли бы
> загружается в виде "пакетов". Но как и сами эти системы, "подгрузка жемстоун
> способностей" выглядит невероятно :)
>
> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].

Настройки подписки и доставки писем: https://groups.google.com/d/optout.

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.