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

Если придерживаться правила, что любой объект может быть не загружен в память, а вместо этого — пока можно — представляться заглушкой (которую можно передавать куда-то и, может быть, даже какие-то сообщения ей посылать), то c allInstances проблем, вроде, не видно. Или я что-то упускаю?

А с GC в чем проблема? Учитывая, что его состояние так же может выгружаться? И что внешняя память дешева — наверное, можно позволить себе чистить мусор, который был выгружен из памяти, не слишком часто.

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 14:15 пользователь Alexander Kogan <[hidden email]> написал:

сделать можно все. Не боги горшки обжигают.
 Магма казалось бы на самом деле не плохая стартовая точка. но
ньюансов  много. Большие проблемы начинаются скажем c GC очень
большого образа, большая часть которого на диске, а не в памяти. или
вещи типа allInstances

2014-12-03 2:03 GMT-08:00 Alexander Kogan <[hidden email]>:

> Вопрос чем  лучше ООБД немного  из разряда. Чем Smaltalk лучше С,
> Java(нужное вставить). Зависит от поставленых задач наверно. Частично
> ответ был озвучен, думать меньше надо,  не надо озадачиваться
> поддержкой и совместимостью двух или более продуктов. Из последнего
> вытекает более важный момент. Если код имеет потенциал мутировать, то
> скажем добавить переменную и еще одно поле в базу это куда ни шло, а
> вот добавить subclass да еще с дополнительными связями на комплексный
> обьект(ы) может уже стать существенным препоном. Начинают вылезать
> дополнительные таблицы, ключи, нормализация. А в OOБД,ну добавил и
> добавил. Set все стерпит.
>
> 2014-12-03 1:32 GMT-08:00 Nikolay Kleptsov <[hidden email]>:
>> А я считаю что можно, если слепо не копировать GemStone. В качестве внешнего
>> хранилища данных использовать либо БД либо файловую систему. Дополнительный
>> образ контроллер будет определять кто, где хранит части базы и откуда
>> загружать данные. Контроль сессии, прав пользователей, конкуренция
>> процессов. Контроллер управляет несколькими образами кешами, отдельные
>> образы могут иметь свое хранилище, другие разделять.
>>
>> 3 декабря 2014 г., 15:20 пользователь Denis Kudriashov
>> <[hidden email]> написал:
>>
>>> Как работает жемстоун мне известно. Вопрос же Дениса о том, возможно ли в
>>> фаре подобное реализовать на самом смолтолке, не выходя за рамки виртуальной
>>> машины. Мой ответ - нельзя. Такое возможно только в системе типа
>>> BeeSmalltalk, если, конечно, это вообще возможно. Но лет десять назад,
>>> вероятно, никто и подумать не мог, что можно создать смолтолк, в котором и
>>> GC, и JIT является частью имиджа, а не виртуальной машины.
>>>
>>> 3 декабря 2014 г., 2:18 пользователь 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.
>>>
>>>
>>> --
>>> --
>>> 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.

3 декабря 2014 г., 13:21 пользователь Юрий Мироненко <[hidden email]> написал:

Вот я и пытаюсь понять, какие задачи ООБД позволит решать эффективнее, чем реляционная база с ОРМ. При желании ОРМ можно сделать более-менее самонастраивающимся и автоматически конфигурирующим базу.

Если у вас сложная объектная модель  со множеством взаимосвязей, в том числе циклических, к которой прикручена сложная бизнес логика.
ОРМ предоставляет крайне ограниченные возможности, заставляющие думать не о том, как правильнее организовать бизнес логику, а о том, получится ли ее замепить в таблицы. У меня это частое явление: получаешь определенную модель, а потом, думаешь: меппинг такой модели будет слишком сложен в поддержке необходимой структуры таблиц, так что проще "захачить" модель, упростив структуру таблиц.

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

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

А я считаю что можно, если слепо не копировать GemStone. В качестве внешнего хранилища данных использовать либо БД либо файловую систему. Дополнительный образ контроллер будет определять кто, где хранит части базы и откуда загружать данные. Контроль сессии, прав пользователей, конкуренция процессов. Контроллер управляет несколькими образами кешами, отдельные образы могут иметь свое хранилище, другие разделять.

А чем это будет отличаться от Магмы?

У жемстоуна все объекты просто лежат в имидже, И как написал Александр, в память объекты из имиджа подгружаются по мере необходимости. Работает механизм виртуальной памяти операционной системы, только со специфичной реализацией жемстоуна. И когда выполняется какой-то код, то практически нет издержек на получение объектов, в отличие от их загрузки из "других процессов" (типа внешней базы), все происходит в одном адресном пространстве. Все объекты уже в имидже. А в случае с Магмой, эти объекты приходится в имидж загружать.

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

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

3 декабря 2014 г., 13:03 пользователь Alexander Kogan <[hidden email]> написал:

Вопрос чем  лучше ООБД немного  из разряда. Чем Smaltalk лучше С,
Java(нужное вставить). Зависит от поставленых задач наверно. Частично
ответ был озвучен, думать меньше надо,  не надо озадачиваться
поддержкой и совместимостью двух или более продуктов. Из последнего
вытекает более важный момент. Если код имеет потенциал мутировать, то
скажем добавить переменную и еще одно поле в базу это куда ни шло, а
вот добавить subclass да еще с дополнительными связями на комплексный
обьект(ы) может уже стать существенным препоном. Начинают вылезать
дополнительные таблицы, ключи, нормализация. А в OOБД,ну добавил и
добавил. Set все стерпит.

+100

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