Здравствуйте, shuklin, Вы писали:
S>Я это уже сделал.
Ты ничего пока не сделал. Проблема не в дескрипторах, а в клиентских приложениях. Если клиентское приложение ничего не знает о городах, то сколько там дескрипторов ни наверни, работать лучше оно не станет.

Здравствуйте, Sinclair, Вы писали:

S>Ты ничего пока не сделал. Проблема не в дескрипторах, а в клиентских приложениях. Если клиентское приложение ничего не знает о городах, то сколько там дескрипторов ни наверни, работать лучше оно не станет.

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

Здравствуйте, Sinclair, Вы писали:

S>>Я это уже сделал.
S>Ты ничего пока не сделал. Проблема не в дескрипторах, а в клиентских приложениях.

И еще, похоже я плохо объяснил свою мысль. Не дескриптор решает эту проблему, а дескриптор иллюстрирует на своем примере использование одного из механизмов моей СУБД (использование IContainerEvents интерфейса) который может быть использован для построения объектного VIEW. Собственно FieldDescriptor является таким объектным VIEW/JOIN. FieldDescriptor JOINит собственные данные с данными AttributeDescriptor. Цели для которых это сделано никакого отношения к рассматриваемой проблеме не имеют. Это просто указание, какой кусок исходников смотреть, если интересно понять, о чем я говорю.

Здравствуйте, shuklin, Вы писали:

S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

Мне близка Ваша тема, я сейчас думаю над языковой-хранилище средой, построенной на принципах метафреймов. Копать же вплоть до ОС мне кажется непосильной задачей.

Мне кажется, стоит пробовать обкатывать те или иные идеи в этой области с малого.

AVC>>А в vi все просто: yy999p :)

L>Разработчики студии, видимо, справедливо решили что такая возможность программисту не нужна.
Это не "такая возможность". Это просто несколько команд на языке vim-а. yy (скопировать) 999p — вставить 999 раз. Потом, что значит не нужна. 1000 раз может и не нужна, просто скопировать несколько строк — вполне обычное дело.

L>Ничего сложного, правда? Поверте, это достаточно быстро — секунд 15 и нагляднее, по-моему, чем yy999p.
Это никак не 15 секунд — сначала пришлось бы изучать бейсик или что это было.

Здравствуйте, dmz, Вы писали:

dmz>Это не "такая возможность". Это просто несколько команд на языке vim-а. yy (скопировать) 999p — вставить 999 раз. Потом, что значит не нужна. 1000 раз может и не нужна, просто скопировать несколько строк — вполне обычное дело.
"просто скопировать несколько строк" гораздо проще с помощью мыши.

L>>Ничего сложного, правда? Поверте, это достаточно быстро — секунд 15 и нагляднее, по-моему, чем yy999p.
dmz>Это никак не 15 секунд — сначала пришлось бы изучать бейсик или что это было.
О да, а знание команд vim наверное инсталлируется прямо в мозг при первом запуске. Этот VBA к тому же обладает интеллисенсом и подсказывает, что можно сделать, имена объектов и методов выбраны так, чтобы типичный американец сразу знал, что куда вставлять, а кроме всего прочего, можно включить запись макроса. Поэтому типичная штука — это включить запись, вбить параграф, выключить запись, пойти в редактор макросов и обложить две строчки циклом. Я так в свое время выполнял подбор параметра в Excel для 2000 начальных условий.

Здравствуйте, yrashk, Вы писали:


Y>Мне близка Ваша тема, я сейчас думаю над языковой-хранилище средой, построенной на принципах метафреймов. Копать же вплоть до ОС мне кажется непосильной задачей.

Y>Мне кажется, стоит пробовать обкатывать те или иные идеи в этой области с малого.

Полностью согласен. Что ты понимаешь под метафреймами? На какой стадии находится твоя работа? Я уже где то год обкатываю свои идеи на изготовленном движке ООБД. Уже опубликовал несколько версий. Если заинтересуешся — можешь посмотреть. Буду рад любому сотрудничеству.

Дмитрий.

shuklin wrote:
>
> Y>Мне близка Ваша тема, я сейчас думаю над языковой-хранилище средой,
> построенной на принципах метафреймов. Копать же вплоть до ОС мне кажется
> непосильной задачей.
>
> Y>Мне кажется, стоит пробовать обкатывать те или иные идеи в этой
> области с малого.
>
> Полностью согласен. Что ты понимаешь под метафреймами? На какой стадии
> находится твоя работа? Я уже где то год обкатываю свои идеи на
> изготовленном движке ООБД. Уже опубликовал несколько версий. Если
> заинтересуешся — можешь посмотреть. Буду рад любому сотрудничеству.

Под метафреймом я понимаю такую модель:

— Ссылка на метаобъект данного объекта; Значение
-- Ссылка на метаобъект слота 1; Значение
-- Ссылка на метаобъект слота 2; Значение
---- Ссылка на метаобъект слота 2.1; Значение

(если рассматривать упрощенно)

У меня моя работа находится в фазе перманетного обдумывания, с
некоторыми отворотами-исследованиями в сторону (типа http://verb.org.ua/om/)

Сейчас же я пытаюсь начать набрасывать рантайм (http://verb.org.ua/xi/,
исходников пока, увы, нет)

Основная мысль заключается в том, что на базе метафреймов описывается
ВСЁ, включая и конструкции для вычислений, и необходимые данные.
Соответственно, мы можем сделать метафреймовый язык с persistent store.
Такое вот.

С уважением,
Юрий.

Здравствуйте, yrashk, Вы писали:


Y>Под метафреймом я понимаю такую модель:

Y>- Ссылка на метаобъект данного объекта; Значение
Y>-- Ссылка на метаобъект слота 1; Значение
Y>-- Ссылка на метаобъект слота 2; Значение
Y>---- Ссылка на метаобъект слота 2.1; Значение

Если под ссылкой на метаобъект ты понимаешь ссылку на некоторый экземпляр, описывающий семантику данного экземпляра, причем в отношении много значений к одному описателю — то именно такую архитектуру я в своей ООБД уже реализовал.

Если под метаобъектом ты понимаешь нечто отличное от описателя — тогда я не понял идеи, опиши пожалуйста подробнее.

Дмитрий.

Здравствуйте, shuklin, Вы писали:
Y>>Под метафреймом я понимаю такую модель:

Y>>- Ссылка на метаобъект данного объекта; Значение
Y>>-- Ссылка на метаобъект слота 1; Значение
Y>>-- Ссылка на метаобъект слота 2; Значение
Y>>---- Ссылка на метаобъект слота 2.1; Значение

S>Если под ссылкой на метаобъект ты понимаешь ссылку на некоторый экземпляр, описывающий семантику данного экземпляра, причем в отношении много значений к одному описателю — то именно такую архитектуру я в своей ООБД уже реализовал.

S>Если под метаобъектом ты понимаешь нечто отличное от описателя — тогда я не понял идеи, опиши пожалуйста подробнее.

Если я правильно тебя понимаю, то приблизительно это я и имею в виду. Для уточнения
Предположим, у нас есть объект OneKilo (названия здесь и далее только лишь для удобства). Значение, предположим, (uint32_t)1024 (4 байта). У объекта OneKilo метаобъектом может быть объект Number, у которого собственный метаобъект, например, Object.
У объекта Number может быть, для примера, слоты
— (мета=SymbolicName) "Number"
в свою очередь, SymbolicName может иметь метой Symbol или Object.
Это, в целом, уже вопрос устаканивания набора базовых фреймов. Например, я хочу чтобы мета-отношения были также предметом отношения фрейм-слот, т.е. нужен объект META, на который также ссылаются, и т.п.

Это все немного поверхностно, в отличии от того, что продумывается, но, надеюсь, должно дать общую картинку.

Здравствуйте, yrashk, Вы писали:


Y>Если я правильно тебя понимаю, то приблизительно это я и имею в виду. Для уточнения
Y>Предположим, у нас есть объект OneKilo (названия здесь и далее только лишь для удобства). Значение, предположим, (uint32_t)1024 (4 байта). У объекта OneKilo метаобъектом может быть объект Number, у которого собственный метаобъект, например, Object.


Ориентировочно понял. Да очень похоже на то что и я сделал. Можешь посмотреть на детали моего творчества по этому поводу здесь http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx там с серидины статьи идет описание AttributeDescriptor и TableDescriptor Мне очень интересно обсудить различия в наших подходах.

Здравствуйте, shuklin, Вы писали:

S>Здравствуйте, yrashk, Вы писали:


Y>>Если я правильно тебя понимаю, то приблизительно это я и имею в виду. Для уточнения
Y>>Предположим, у нас есть объект OneKilo (названия здесь и далее только лишь для удобства). Значение, предположим, (uint32_t)1024 (4 байта). У объекта OneKilo метаобъектом может быть объект Number, у которого собственный метаобъект, например, Object.


S>Ориентировочно понял. Да очень похоже на то что и я сделал. Можешь посмотреть на детали моего творчества по этому поводу здесь http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx там с серидины статьи идет описание AttributeDescriptor и TableDescriptor Мне очень интересно обсудить различия в наших подходах.

Спасибо за ссылку, я просмотрел. Пока, навскидку, я вижу такие отличия:

1. Я пытаюсь идти путём полной последовательности в формировании объектов.
У меня нету специальных Name/DisplayName/Description. Это все должно быть описано в форме отношений фрейм-слот, и мета-отношений. Мне кажется, этот подход позволяет не ограничивать себя так или иначе и создавать более гибкую модель.
2. У меня фактически нет разделения типа Attribute/Table. У меня все является объектом, а "вложенность" описывается посредством отношений фрейм-слот
3. Так как я планирую гибрид языка и базы данных, меня интересует собственный memory allocation manager в своих участках памяти (маппленых). Т.е. я не хочу базироваться на какой-то low level (bdb, например) или high level (*sql) базе данных.
4. Я в основном *nix-разработчик, и практически не использую (да и не знаю особо) .NET. Только ради пробы какие-то hello world на mono писал.

Вот пока такие различия усмотрел.

Здравствуйте, yrashk, Вы писали:

Y>У меня нету специальных Name/DisplayName/Description. Это все должно быть описано в форме отношений фрейм-слот, и мета-отношений. Мне кажется, этот подход позволяет не ограничивать себя так или иначе и создавать более гибкую модель.

У меня эти свойства тоже не являются специальными, но без них будет совсем неудобно. Поэтому я их создаю зарание про запас.

Y>2. У меня фактически нет разделения типа Attribute/Table. У меня все является объектом, а "вложенность" описывается посредством отношений фрейм-слот

У меня таблицы могут быть аттрибутами, к примеру. Тоже нет ограничений. Просто совсем без конкретики не удобно. Ее придется вводить. Вот рекомендуемое разделение аттрибутов и таблиц есть одно из таких решений. Это уже модель внутри модели. Причем служебная модель для обслуги собственных целей ООБД. Там все сделано так как было удобнее для самой ОБД. А вот пользователи могут творить все что захотят, делать объекты собственными аттрибутами, или парентами, назначать одному и тому же экземпляру различные ID, либо одному и тому же ID назначать различные объекты (в различных контекстах разадресации) Модель данных моей ООБД сетевая — никаких таблиц. Только граф и однонаправленные связи. Узлы можно рассматривать как фреймы, а связи — как слоты. На основе примененной модели данных легко реализуются иерархические семантические сети, иерархические сети фреймов, модель близкая к реляционной (используется для конфигурации ядра), нейронные сети.

Y>3. Так как я планирую гибрид языка и базы данных, меня интересует собственный memory allocation manager в своих участках памяти (маппленых). Т.е. я не хочу базироваться на какой-то low level (bdb, например) или high level (*sql) базе данных.

У меня сейчас работают 3 сборщика мусора. Из них один — MSовский из .NET и два собственного изготовления. Надо сказать МС овский для ОБД подходит плохо, с ним приходится бороться.

Y>4. Я в основном *nix-разработчик, и практически не использую (да и не знаю особо) .NET. Только ради пробы какие-то hello world на mono писал.

Ага, это наверное основное. Я свое изделие под *nix не планирую портировать никогда, хотя потенциальную возможность такого порта заложил. Это технически возможно. Я — win разработчик и целевая аудитория *nix для моей ООБД мне не интересна.

Здравствуйте, shuklin, Вы писали:

Y>>У меня нету специальных Name/DisplayName/Description. Это все должно быть описано в форме отношений фрейм-слот, и мета-отношений. Мне кажется, этот подход позволяет не ограничивать себя так или иначе и создавать более гибкую модель.

S>У меня эти свойства тоже не являются специальными, но без них будет совсем неудобно. Поэтому я их создаю зарание про запас.

Я пришёл к выводу, что мне никто не мешает добавить слоты с метами Name/DisplayName/Description к тому объекту, которому я хочу, и тогда, когда я этого хочу.

Y>>2. У меня фактически нет разделения типа Attribute/Table. У меня все является объектом, а "вложенность" описывается посредством отношений фрейм-слот

S>У меня таблицы могут быть аттрибутами, к примеру. Тоже нет ограничений. Просто совсем без конкретики не удобно. Ее придется вводить. Вот рекомендуемое разделение аттрибутов и таблиц есть одно из таких решений. Это уже модель внутри модели. Причем служебная модель для обслуги собственных целей ООБД. Там все сделано так как было удобнее для самой ОБД. А вот пользователи могут творить все что захотят, делать объекты собственными аттрибутами, или парентами, назначать одному и тому же экземпляру различные ID, либо одному и тому же ID назначать различные объекты (в различных контекстах разадресации) Модель данных моей ООБД сетевая — никаких таблиц. Только граф и однонаправленные связи. Узлы можно рассматривать как фреймы, а связи — как слоты. На основе примененной модели данных легко реализуются иерархические семантические сети, иерархические сети фреймов, модель близкая к реляционной (используется для конфигурации ядра), нейронные сети.

То есть в приниципе можно рассатривать Attribute/Table как предмет описания фрейм-слот отношений?

Y>>3. Так как я планирую гибрид языка и базы данных, меня интересует собственный memory allocation manager в своих участках памяти (маппленых). Т.е. я не хочу базироваться на какой-то low level (bdb, например) или high level (*sql) базе данных.

S>У меня сейчас работают 3 сборщика мусора. Из них один — MSовский из .NET и два собственного изготовления. Надо сказать МС овский для ОБД подходит плохо, с ним приходится бороться.

А вот тут хотелось бы подробнее, мне интересно. Возможно ли в .NET взять кусок памяти некоего размера, и самостоятельно с ним работать? А взять его не просто из свободной памяти, а из файла (т.е. Memory Mapped File)? Т.е. как вот в *nix я делаю mmap() и дальше танцую оттуда.

Есть ли что-то в этом направлении?

Y>>4. Я в основном *nix-разработчик, и практически не использую (да и не знаю особо) .NET. Только ради пробы какие-то hello world на mono писал.

S>Ага, это наверное основное. Я свое изделие под *nix не планирую портировать никогда, хотя потенциальную возможность такого порта заложил. Это технически возможно. Я — win разработчик и целевая аудитория *nix для моей ООБД мне не интересна.

Мне лично это не кажется основным различием, по крайней мере идеологическим.

Здравствуйте, yrashk, Вы писали:


Y>Я пришёл к выводу, что мне никто не мешает добавить слоты с метами Name/DisplayName/Description к тому объекту, которому я хочу, и тогда, когда я этого хочу.

Правильно. В моей ОБД любой слот можно добавлять к любому объекту в любое удобное время. Можно сказать, что потенциально все объекты обладают всеми аттрибутами + все объекты являются аттрибутами и все аттрибуты являются объектами. Но это потенциально. В какой то конкретной БД только определенные экземпляры являются аттрибутами у определенных экземпляров. Любой экземпляр объекта можно сделать аттрибутом какого то экземпляра объекта. Учитывая всеже необходимость минимального порядка, все равно будут существовать ограничения, но они накладываются не БД а задачей. Что делает с одной стороны такой инструмент мощным, а с другой, утяжеляет поиск ошибок, т.к. можно сделать всю таблицу значением аттрибута "Name" и при попытке привести ее к типу String получить толи экзепшин толи результат Table.ToString() — это уш как повезет, но по любому результат без смысла )) Т.к. БД позволяет максимальную свободу — ответственность разработчика избегать нарушений такого характера. В мои интересы именно такая свобода и входит как первоочередной приоритет. constraints можно накрутить уже потом, по мере необходимости.


Y>То есть в приниципе можно рассатривать Attribute/Table как предмет описания фрейм-слот отношений?

Да, можно, Attribute/Table является частным случаем применения фрейм-слот отношений. При реализации Attribute/Table были задействованы более низкоуровневые возможности модели данных (графа).

Y>А вот тут хотелось бы подробнее, мне интересно. Возможно ли в .NET взять кусок памяти некоего размера, и самостоятельно с ним работать? А взять его не просто из свободной памяти, а из файла (т.е. Memory Mapped File)? Т.е. как вот в *nix я делаю mmap() и дальше танцую оттуда.

В .NET куча интересных возможностей. Меня прежде всего заинтересовал MC++ он позволяет в одном коде перемешивать IL и старый добрый ASM (не на прямую, а как результат компиляции C++ — управляемо через pragma какой кусочек сырца куда скомпилится) Память на прямую можно использовать и из C# — там есть понятие указатель, хотя оно включается специальной опцией компилятора, и с такой сборокой будут проблемы при попытке ее запуска из под IE к примеру. Но для собственной ООБД это не принципиально, по любому сервайсу придется отдавать почти все права. Еще я очень активно использую "mixed" классы. Тоесть обычные структуры в памяти, методы к которым частично реализованы на IL и частично на unmanaged code При этом virtual методы overrided тоже в mixed режиме. В базовом классе метод может быть реализован на unmanaged code и перекрыт managed у наследника, и далее опять unmanaged. Ну это все внутренности. Наружу торчит только C# интерфейс.

Прямое отображение файла в память я решил не использовать, несмотря на возможный выигрыш в производительности. Пытался, но пришел к тому, что потеряю больше чем получу. Если твоя БД требует прямого отображения, то в Win32 есть соответсвующее API а что C# что MC++ может им воспользоваться. Хотя удобно это не будет. Мало того, есть интересные результаты тестов. В некоторых сценариях C# опережает по скорости C++. Это связано со стековым выделением памяти в .NET и heap в С++. Есть ли аналог MC++ для Mono я не знаю. И какое АПИ доступно из Mono — тоже не знаю. В самом .NET на сколько мне известно memory mapped files не поддерживаются — только как внешнее OSAPI.

Y>Мне лично это не кажется основным различием, по крайней мере идеологическим.

Да, это различие исключительно политическое )) Можем сотрудничать на идеологической основе, она у нас очень близкая. Сможем обогатить системы друг друга полезными идеями. Я свою делаю в первую очередь для моделирования нейронных сетей, хотя и стандартные бизнес сценарии мне тоже интересны. А ты для чего свою?

Здравствуйте, shuklin, Вы писали:


Y>>А вот тут хотелось бы подробнее, мне интересно. Возможно ли в .NET взять кусок памяти некоего размера, и самостоятельно с ним работать? А взять его не просто из свободной памяти, а из файла (т.е. Memory Mapped File)? Т.е. как вот в *nix я делаю mmap() и дальше танцую оттуда.

S>Прямое отображение файла в память я решил не использовать, несмотря на возможный выигрыш в производительности. Пытался, но пришел к тому, что потеряю больше чем получу. Если твоя БД требует прямого отображения, то в Win32 есть соответсвующее API а что C# что MC++ может им воспользоваться. Хотя удобно это не будет. Мало того, есть интересные результаты тестов. В некоторых сценариях C# опережает по скорости C++. Это связано со стековым выделением памяти в .NET и heap в С++. Есть ли аналог MC++ для Mono я не знаю. И какое АПИ доступно из Mono — тоже не знаю. В самом .NET на сколько мне известно memory mapped files не поддерживаются — только как внешнее OSAPI.

Надо бы почитать документацию по Mono, интереса ради. В том числе и по поводу OS API, вызовов mmap() и работы с этим всем.

У меня же требуется прямое отображение по тому соображению (но не только), что у меня не совсем БД, а некий "язык программирования" с полной и прозрачной персистентностью.

Y>>Мне лично это не кажется основным различием, по крайней мере идеологическим.

S>Да, это различие исключительно политическое )) Можем сотрудничать на идеологической основе, она у нас очень близкая. Сможем обогатить системы друг друга полезными идеями. Я свою делаю в первую очередь для моделирования нейронных сетей, хотя и стандартные бизнес сценарии мне тоже интересны. А ты для чего свою?

Ближе к "бизнес-сценариям", я нейронками не занимаюсь в данный момент. Хотя всё возможно, есть некие выходы на интересные работы в этом направлении.

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

Здравствуйте, shuklin, Вы писали:

S>Прямое отображение файла в память я решил не использовать, несмотря на возможный выигрыш в производительности. Пытался, но пришел к тому, что потеряю больше чем получу. Если твоя БД требует прямого отображения, то в Win32 есть соответсвующее API а что C# что MC++ может им воспользоваться. Хотя удобно это не будет. Мало того, есть интересные результаты тестов. В некоторых сценариях C# опережает по скорости C++. Это связано со стековым выделением памяти в .NET и heap в С++. Есть ли аналог MC++ для Mono я не знаю. И какое АПИ доступно из Mono — тоже не знаю. В самом .NET на сколько мне известно memory mapped files не поддерживаются — только как внешнее OSAPI.

В Mono есть класс Mono.Unix.Native.Syscall, в котором есть и mmap

Здравствуйте, yrashk, Вы писали:


Y>Надо бы почитать документацию по Mono, интереса ради. В том числе и по поводу OS API, вызовов mmap() и работы с этим всем.

Да, всего интересного много есть в природе. Приходится оптимизировать затраты на собственное обучение чтоб не превратить этот процесс в китайский университет. И поэтому тоже я не смотрю в сторону *nix — просто не хватит рессурсов поддерживать две платформы.

Y>У меня же требуется прямое отображение по тому соображению (но не только), что у меня не совсем БД, а некий "язык программирования" с полной и прозрачной персистентностью.

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

если начать избавляться от этих моментов — то в итоге классическая сериализация окажется и эффективнее и проще по сравнению с отображением в котором сортируются поля, динамически подменяются мягкие ссылки и пр.

Я решил, в файле буду хранить данные максимально компактно чтоб уменьшить трафик, а в озу — как будет быстрее их обработать.


Y>Ближе к "бизнес-сценариям", я нейронками не занимаюсь в данный момент. Хотя всё возможно, есть некие выходы на интересные работы в этом направлении.

Мне тоже пришлось в бизнес сценариях поработать с ОРМ и SQL-XML связками для business logic teirs ИМХО ОБД может быть весьма полезна во многих областях бизнеса. Поэтому я обращаю на возможность такого применения своей ОБД первоочередное внимание. Уже в собственных планах выпуск на ее основе совершенно обычных продуктов без ИИ+ИНС.

Здравствуйте, shuklin, Вы писали:

Y>>Надо бы почитать документацию по Mono, интереса ради. В том числе и по поводу OS API, вызовов mmap() и работы с этим всем.

S>Да, всего интересного много есть в природе. Приходится оптимизировать затраты на собственное обучение чтоб не превратить этот процесс в китайский университет. И поэтому тоже я не смотрю в сторону *nix — просто не хватит рессурсов поддерживать две платформы.

А у меня вряд ли хватит ресурсов на поддержку развития в сторону Windows. Я последний раз под него писал году эдак в 96-97.

Y>>У меня же требуется прямое отображение по тому соображению (но не только), что у меня не совсем БД, а некий "язык программирования" с полной и прозрачной персистентностью.

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

Что имеется в виду под мягкими ссылками? weak pointers? Что именно ты считаешь мусором, которому не стоит уходить на диск?

S>- очень много аттрибутов объектов сохранять нет необходимости. при отображении они будут забивать диски.

А можно пример, когда неоторые аттрибуты сохранять нет необходимости?

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

S>Я решил, в файле буду хранить данные максимально компактно чтоб уменьшить трафик, а в озу — как будет быстрее их обработать.

Кстати. Является ли твое решение transactionable? А то я после просмотра материала не понял этого.

А насчет отображений -- знаешь ли ты такие модели как images (во многих реализациях Lisp, Smalltalk, etc.)? Я в некотором роде оттуда наследую модель отображения, так как некоторым боком любитель Lisp/Smalltalk/etc.

Y>>Ближе к "бизнес-сценариям", я нейронками не занимаюсь в данный момент. Хотя всё возможно, есть некие выходы на интересные работы в этом направлении.

S>Мне тоже пришлось в бизнес сценариях поработать с ОРМ и SQL-XML связками для business logic teirs ИМХО ОБД может быть весьма полезна во многих областях бизнеса. Поэтому я обращаю на возможность такого применения своей ОБД первоочередное внимание. Уже в собственных планах выпуск на ее основе совершенно обычных продуктов без ИИ+ИНС.

Замечательно!

Здравствуйте, yrashk, Вы писали:


Y>Что имеется в виду под мягкими ссылками? weak pointers? Что именно ты считаешь мусором, которому не стоит уходить на диск?

на сколько я знаю, soft pointers общепринятое название в противовес слабым ссылкам (weak pointers)
Ну допустим у нас есть циклический двусвязный список из пользовательских экземпляров объектов. И пусть в этом списке будет миллион инстансов. В какой то момент нужно обратится к 10000 объекту и отшагать в перед до 11000. Пусть у нас уже есть какой то способ попасть в 10000 напрямую. Итак мы вытянули 10000 в память. он указывает на 9999 и на 10001. Должны ли мы вытягивать и их тоже? Если да — то в итоге мы вытяним весь миллион. он забъет своб ОС и перформанс будет мизерный (это еще если все не рухнет). Если мы не будем вытягивать 9999 и 10001 до тех пор пока они нам не понядобятся, возникнет вопрос, а куда указывают ссылки prev, next из 10000? Для решения этого дело делают или объекты плайсхолдеры, которые заменяются при обращении к ним на настоящие, или мягкие указатели, которые указывают на область диска где расположен объект до того как произойдет инстанциация, после чего они будут указывать уже на область памяти. Как минимум в таком указателе в ram нужно 2 поля — указатель в память и на диск. А вот на диск сбрасывать указатели на объекты в рам смысла нет ни какого. На диске это просто мусор. Я использую мягкие ссылки.


Y>А можно пример, когда неоторые аттрибуты сохранять нет необходимости?

какие нибудь временные объекты. К примеру в моей ОБД не сохраняются TableView (аналог System.Data.DataView но для моих табличек)


Y>Кстати, в моей модели планируется такая штука, как объекты, которые не записываются, в рамках всё той же метафреймовой модели. В метафрейме объекта должно быть просто указание необходимости записи "обратно" в файл, или что-то вроде этого.

Да. Это важно.


Y>Кстати. Является ли твое решение transactionable? А то я после просмотра материала не понял этого.

Ну это интересный вопрос. В текущей версии формально — да. Тот же пример Streams-01 если его запустить позволяет сделать commit|rollback. Но фактически простых commit|rollback в реальной жизни (по крайней мере мне) в том виде в котором я это реализовал на данный момент (in memory snapshot) совершенно недостаточно. Поэтому я продолжаю работу в этом направлении. В будущих версиях поддержка транзакций будет по интереснее. Какая — расскажу после выпуска.

Y>А насчет отображений -- знаешь ли ты такие модели как images (во многих реализациях Lisp, Smalltalk, etc.)? Я в некотором роде оттуда наследую модель отображения, так как некоторым боком любитель Lisp/Smalltalk/etc.

Нет, этого я не знаю. ((( Какая там основная фишка?