Персистенс
Locked
 
|
Всем привет!
Застарелый вопрос снова всплыл. Ковыряюсь сейчас я в свободное время с одной задачкой. Задачка эта требует сохранять объекты. И решил я использовать для этого CouchDB. Но вопрос мой, думаю, не зависит от типа хранилища. А вопрос такой: есть ли какие-либо общепринятые подходы к организации персистенса в Smalltalk-системах? Собственных знаний не хватает. Несколько раз к этому вопросу в своей практике подходил, но не разу так и не решил. Беру помощь зала :) В подходе "попроще" напрягает невозможность избежать дублирования функциональности. Элементарный пример: у всех объектов должны быть ключи. (В моем случае это UUID, но это не важно?) Наследованием это делать, конечно, плохо. Аспекты? Может быть, есть какие-то варианты, о которых я не знаю? Примерно та же история, например, с хранилищем: объекты нужно куда-то сохранять. Так или иначе, нужно знать, куда сохранять. Хранить это знание глобально — очень плохо. Систему будет нельзя тестировать параллельно с работой. Хорошо бы иметь некий механизм "параметризации" хранилищем. Хранить эту информацию в самих объектах — дублирование. Придумывать всякие трюки (как в Seaside) с замыканиями и исключениями — интересно, но на практике получается overkill. Слишком сложно для понимания и отладки. Есть еще варианты? Или единственно возможный подход — делать это все на самом наисистемнейшем уровне, как в GemStone? -- Dennis Schetinin -- http://groups.google.ru/group/sugr |
|
|
2010/11/8 Dennis Schetinin <[hidden email]>:
> Всем привет! > > Застарелый вопрос снова всплыл. Ковыряюсь сейчас я в свободное время с одной > задачкой. Задачка эта требует сохранять объекты. И решил я использовать для > этого CouchDB. Но вопрос мой, думаю, не зависит от типа хранилища. А вопрос > такой: есть ли какие-либо общепринятые подходы к организации персистенса в > Smalltalk-системах? Собственных знаний не хватает. Несколько раз к этому > вопросу в своей практике подходил, но не разу так и не решил. Беру помощь > зала :) > > В подходе "попроще" напрягает невозможность избежать дублирования > функциональности. Элементарный пример: у всех объектов должны быть ключи. (В > моем случае это UUID, но это не важно?) Наследованием это делать, конечно, > плохо. Аспекты? Может быть, есть какие-то варианты, о которых я не знаю? > Помоему самый простой и действенный способ. Каждый обьект твоей модели имеет UUID. Этого не избежать в любом случае. Иначе тебе придется организовывать параллельно "регистрилку" в виде Weak..KeyDictionary, который на каждый обьект будет хранить UUID. И все операции придется проводить через эту регистрилку. К Магме сделанно именно так, но там по-другому невозможно, так как она сериализует любые обьекты, а не только определенных свойств (имеющих некий id в виде поля). > Примерно та же история, например, с хранилищем: объекты нужно куда-то > сохранять. Так или иначе, нужно знать, куда сохранять. Хранить это знание > глобально -- очень плохо. Систему будет нельзя тестировать параллельно с > работой. Хорошо бы иметь некий механизм "параметризации" хранилищем. > Хранить эту информацию в самих объектах -- дублирование. Придумывать всякие > трюки (как в Seaside) с замыканиями и исключениями -- интересно, но на > практике получается overkill. Слишком сложно для понимания и отладки. Есть > еще варианты? > не совсем понимаю в чем проблема. Для связи с базой есть некий контрольный обьект - сессия. У сессии есть вся необходимая инфа для работы с ней, в том числее и местонахождение базы. Разные сессии могут использовать разные базы. Сессию можно привязать к процессу (см. #environmentAt: put: в Pharo) тогда легко сделать доступ к сессии, типа: MyObject>>session ^ Processor activeProcess environmentAt: #session (где MyObject это базовый класс твоей модели, который имеет поле id) это все конечно при условии, что обьекты из разных сессий не могут ссылаться друг на друга, иначе получиться каша :) > Или единственно возможный подход -- делать это все на самом наисистемнейшем > уровне, как в GemStone? > все зависит от того, насколько далеко ты хочешь зайти :) > -- > Dennis Schetinin > > -- > http://groups.google.ru/group/sugr -- Best regards, Igor Stasenko AKA sig. -- http://groups.google.ru/group/sugr |
|
|
In reply to this post by Dennis Schetinin
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by Dennis Schetinin
Или единственно возможный подход — делать это все на самом наисистемнейшем уровне, как в GemStone?
А почему как, можно просто использовать Gemstone. Он же бесплатный, до определенного размера конечно. -- http://groups.google.ru/group/sugr |
|
|
In reply to this post by Igor Stasenko
Плохо потому, что наследование — одноразовое оружие. Я же использую его относительно некоторого класса модели. Тогда вся модель должна "танцевать" вокруг сохраняемости. А если мне нужно "концептуально" пронаследоваться от "чужого" класса, который никакого отношения к CouchDB не имеет в принципе? Но, наверное я все-таки переоцениваю эту проблему. По крайней мене пока в моем примере она не проявилась. Наверное, здесь сказывается мое желание сделать модель максимально независимой от сохраняемости: чтобы сначала ни о чем таком не думать и спокойно себе разрабатывать модель предметной области. А потом подмешать что-то эдакое — и готово! :) Все-таки это какая-то ортогональная функциональность. Что там нынче, про аспекты ничего не слышно? Гнилая идея оказалась? Помоему самый простой и действенный способ. Каждый обьект твоей модели О! Про слабый коллекции я как раз и забыл! Буду иметь ввиду этот вариант.
Все равно объекты (либо модели, либо представления) должны знать, куда сохраняться. То есть, — опять — иметь ортогональную к их основным обязанностям функциональность. Сессию можно привязать к процессу (см. #environmentAt: put: в Pharo) Ну, да… Раньше в одной из примочек к Сисайду, кажется, был еще трюк с замыканием и перехватом исключений в нем. Что такое. Кажется. Но проблема в том, что отлаживать это невозможно. В момент отладки ведь активный процесс другой? И в том варианте все ломалось. -- Dennis Schetinin -- http://groups.google.ru/group/sugr |
|
|
In reply to this post by vmusulainen-2
8 ноября 2010 г. 9:37 пользователь Владимир Мусулайнен <[hidden email]> написал:
А там всякие "сложные объекты" корректно сериализуются? К примеру, два документа ссылаются на одного и того же работника. После сериализации/десериализации все так и останется? Вообще, в моей задаче несколько человек могут работать с системой, но их мало и, наверное, можно как-то это ограничить… Если по всем остальным статьям SIXX прокатывает, то это неплохой вариант для моего случая. Спасибо за наводку. … А с SQL-ем связываться не хочу в принципе. :) Спасибо всем ответившим, очень помогли! -- Dennis Schetinin -- http://groups.google.ru/group/sugr |
|
|
In reply to this post by vmusulainen-2
Посмотрел на SIXX — все работает out-of-the-box. Теперь думаю, нет ли смысла скрестить это дело с CouchDB. Дает ли это что-нибудь?
-- Dennis Schetinin -- http://groups.google.ru/group/sugr |
|
|
2010/11/9 Dennis Schetinin <[hidden email]>:
> Посмотрел на SIXX -- все работает out-of-the-box. Теперь думаю, нет ли смысла > скрестить это дело с CouchDB. Дает ли это что-нибудь? > разве что как слой для сериализации обьектов. Но по сути JSON ведь тоже сериализация, поэтому выходит что ты будешь использовать сериализацию дважды. Хотя , если дописать к SIXX модуль , который будет сериализовать обьекты в JSON а не в XML, тогда это будет лучший вариант :) > > -- > Dennis Schetinin > > -- > http://groups.google.ru/group/sugr -- Best regards, Igor Stasenko AKA sig. -- http://groups.google.ru/group/sugr |
|
|
In reply to this post by Dennis Schetinin
|
|
|
In reply to this post by Dennis Schetinin
CONTENTS DELETED
The author has deleted this message.
|
|
|
2010/11/9 Владимир Мусулайнен <[hidden email]>:
>> А там всякие "сложные объекты" корректно сериализуются? К примеру, два >> документа ссылаются на одного и того же работника. После >> сериализации/десериализации все так и останется? > > Да, он корректно отслеживает ссылки на один и тот же объект. > При восстановлении не будет такого, что два документа ссылаются на > двух сотрудников с одинаковыми атрибутами. > Сотрудник будет один и тот же объект. > > > Про SQL.. > При всех недостатках у SQL есть большой плюс - с данными можно > работать напрямую, через SQL клиента. Иногда очень полезно и удобно. > Честно говоря, я не пробовал никогда gemstone, возможно, там все тоже > очень красиво и практично и не отражается на предметной области. > У GemStone один плюс - ты всегда работаешь с обьектами напрямую, без дополнительных сложностей типа составить запрос, а потом прочесть его и т.п., что иногда очень полезно и удобно :) > -- > http://groups.google.ru/group/sugr -- Best regards, Igor Stasenko AKA sig. -- http://groups.google.ru/group/sugr |
|
|
In reply to this post by vmusulainen-2
В Gemstone в приципе все просто. Все что не является предметом Garbage Collection, т.е имеет зацепку ссылку на перманентный обьет. Например, положить колекцию в class variable, или в user namespace, то дальнейшие манипуляции типа добавление/удаление над этой колекцией после комманды commit будут сохранены на диск. С точки зрения написания кода с коллекций работаешь посредством стандартных итераторов do: select: detect: и т.д. Никаких специальных пассов пальцами для того, чтобы достать данные с диска после этого делать не надо. Просто используешь как коллекцию находящаюся в локальной памяти как в любом другом Smalltalk. Если коллекции становяться очень большими, прихдится применять оптимизации, типа индексации instance variables и специальный синтасис вызова итераторов.
2010/11/9 Владимир Мусулайнен <[hidden email]>
-- http://groups.google.ru/group/sugr |
|
|
In reply to this post by Igor Stasenko
Вообще если программа пишется под seaside то рекомендую попробовать GLASS: gemstone + linux + apache + seaside + smalltalk. http://seaside.gemstone.com/downloads.html
A вот тут много можно интересного почитать: http://gemstonesoup.wordpress.com/ 2010/11/9 Igor Stasenko <[hidden email]> 2010/11/9 Владимир Мусулайнен <[hidden email]>: -- http://groups.google.ru/group/sugr |
|
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
Скорость уж точно проблемой быть не должна.
2010/11/9 Владимир Мусулайнен <[hidden email]>
-- http://groups.google.ru/group/sugr |
«
Return to русский язык (Russian)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |