 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Victor Metelitsa 2:5020/400 01 Feb 2002 18:05:53 To : Andrei N.Sobchuck Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- a> <3C566831.3070805@cssc.tat.ru> <rhu53a.2i.ln@server1.mart.cherkassy.ua> a> <3C5A4C84.2050401@cssc.tat.ru> <slmd3a.gt6.ln@server1.mart.cherkassy.ua> a> <3C5A7303.6040900@cssc.tat.ru> <u96e3a.k4m.ln@server1.mart.cherkassy.ua> From: Victor Metelitsa <vvm@cssc.tat.ru> Andrei N.Sobchuck wrote: > Victor Metelitsa wrote: > >>> VM> В каком месте сложно? То, что словари и есть индексы (один из видов), >>>Оптимизация "руками" - анахронизм. >>> > > VM> Что ты имеешь в виду под "оптимизацией руками"? Я предложил обернуть > VM> коллекцию (или расширить ее). Протокол, конечно, должен быть как у > VM> коллекции (add:, remove:, select:) плюс расширения. Расширения включают > VM> в себя механизм индексирования (на основе словарей; можно взять > VM> B-Деревья и что-нибудь еще) и механизм запросов. Hужно ли было > VM> разжевывать до деталей? Что если нет соответствующего индекса, то он не > VM> должен использоваться, что если индексы многоколоночные (например, на > VM> многоключевых словарях), то надо принять решение и выбрать нужный? Я не > VM> вижу особых сложностях в реализации. Я думаю, реально внутри GemStone > VM> оно так уже и устроено, только привязано зачем-то к instance variables и > VM> не доведено до ума. > Этого сейчас нет. Делать самому? То, что ты написал - будет полноценный > сервер. Мне все это кажется настолько простым... Многие компоненты уже готовые, лишь немножко поработать напильником осталось ;-). Только зачем, если всего четыре коннекта? ;-( > Так что, O/R mapping - проще всего. > > Кстати о маппинге. Ко всем. > В результате запроса получили объект на клиенте. > Другой пользователь удалил из базы записи из которых > объект был "собран". > Что с этим уже не существующим объектом должно > происходить на клиенте? Такого просто не может (не должно) быть. Hикаких "записей" не существует, есть просто объекты. Пользователь в результате запроса получил не объект GemStone, а одно из двух: либо "отражение", связанное коннектором с оригинальным GemStone-объектом, либо прокси. Есть на объект GemStone ссылка - он в мусор не попадет; то, что другой пользователь убрал объект из коллекции или откуда-то еще, роли не играет. А ссылка есть (должна быть) обязательно; коннектор и прокси это и есть ссылки, только между разными имиджами. Вот когда первый пользователь разорвет коннект с базой, либо "избавится" от того "отражения" или прокси (их приберет сборщик мусора), тогда только базоданновый объект может отправлиться в мусор. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/5364b9dca267.html, оценка из 5, голосов 10
|
|
|