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

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

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

GZ>>Тут IMHO не все так однозначно. Изменение ссылки точно такая-же логгируемая операция, как и любое изменение объекта. То есть, при изменении, мы должны записать об этом в конце транзакции в лог. Попробуем рассмотреть оба варианта с точки зрения работы лога и транзакций.
GZ>>В первом случае мы получаем, что при окончании транзакции мы сохраняем записи всем скопом в лог, и у нас при этом они кладуться в одну или несколько последовательных страниц.
GZ>>Во втором случае, у нас в случае если транзакция read-only, мы вынуждены открыть ее (а я думаю лучше по соседству другую) как updatable. Но при этом, непонятна длительность этой транзакции, и количество данных которое должно быть сохранено существенно меньше чем размер страницы.

E>Я тоже думаю, что лучше другую. И сразу же ее зафиксировать.
Но тогда получается, что при минимуме данных (там получается практически несколько байт) придется записывать целую страницу.
Я бы пошел дальше. Например организовал отдельный (системный) лог который бы фиксировался либо при достижения объема страницы, либо перед savepoint'ом.

С уважением, Gleb.

Здравствуйте, Alexey Rovdo, Вы писали:
AR>Кстати, возвращаясь к упоминавшемуся мной ранее механизму версионности в FastObjects. Так вот там read-only операции не влияют на объект — он переформатируется в новую версию только тогда, когда приложение его редактирует.
А как насчет ассоциативного запроса? Там разве не взводится Lazy Writer, который в фоновом режиме выполняет конверсию, а получение такого запроса переводит его в foreground?

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

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

GZ>>В объект введено состояние логически удален.
S>Это состояние случайно не влечет за собой запрет ставить новые ссылки на этот объект?
Скорее всего да. И вообще любое редактирование логически удаленного объекта — запретить. Вообще это только намерение. Я пока только уверен, что подобная система нужна.
GZ>>Вообще, удивительно. Это настолько часто используется в бизнес-приложениях, но ни одна тулза (известная мне) не предоставляет средств (кроме каких-то визуальных тулзов для Delphi).
GZ>>И к этому присобачена разного вида ссылки и такая проверка ссылочной целостности при удалении.
GZ>>Тип ссылки 1. Если существует объект на который ссылается, то объект не может быть удален.
GZ>>Тип ссылки 2. Если существует объект на который ссылается, то объект может быть удален только логически
GZ>>Тип ссылки 3. Если существует объект на который ссылается, то оба объекта удаляются вместе (логически или физически)
S>Че-то я уже начинаю тормозить. Завтра перечитаю
Вся эта шняга предназначена для стандартной ситуации. У нас есть живой объект, который ссылается на некоторый справочник. Значение из этого справочника — убили. В результате, при показе этого живого объекта значение логически удаленного показывается, но его нельзя присвоить другому объекту. Точно так-же он недоступен и при редактировании самого справочника. При потери последней ссылки на логически удаленный объект — объект должен удалиться(что зачастую в реальных решениях не делается). Но предполагаю, поскольку это предназначается для ORM, то при удалении будет генерится очень нехилый select или набор select'ов для проверки как возможности удаления, так и для удаления связанных. Возможно здесь подсчет ссылок был бы полезней, если бы не его проблемы и требования того, что ORM можно напустить практически на любую базу.

С уважением, Gleb.

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

GZ>Но предполагаю, поскольку это предназначается для ORM, то при удалении будет генерится очень нехилый select или набор select'ов для проверки как возможности удаления, так и для удаления связанных.
Ну, вот RDBMS например этого почему-то не боятся. Delete всегда проверяет все foreign key. И ничего — вроде как-то живет. В основном благодаря тому, что FK — это всегда индекс; а также потому, что этих FK редко бывает много. Ну сослались на меня из десяти мест — это уже какая-то экзотика пошла.
Правда, в OODBMS тут есть некоторая тонкость, связанная с более слабой типизацией. В RDBMS у нас FK всегда попадает ровно в одну таблицу, а стало быть и в обратную сторону связей будет немного. А в ODBMS у нас ссылка может указывать на любого потомка. Так что это может привести к увеличению области сканирования: при использовании везде ссылок на System.Object придется при каждом удалении проверять абсолютно все ссылочные поля!
Без практики применения невозможно сказать, насколько проверка наличия ссылок на себя в типичной OODB дороже, чем в RDB.
GZ>Возможно здесь подсчет ссылок был бы полезней, если бы не его проблемы и требования того, что ORM можно напустить практически на любую базу.
Сам по себе подсчет ссылок — всего лишь кэширование результатов поискового запроса. Этакая денормализация.

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

S>Здравствуйте, Alexey Rovdo, Вы писали:
AR>>Кстати, возвращаясь к упоминавшемуся мной ранее механизму версионности в FastObjects. Так вот там read-only операции не влияют на объект — он переформатируется в новую версию только тогда, когда приложение его редактирует.
S>А как насчет ассоциативного запроса? Там разве не взводится Lazy Writer, который в фоновом режиме выполняет конверсию, а получение такого запроса переводит его в foreground?

PTXX automatically registers changes in the class dictionary, but it does not change the objects in the
database. However, FastObjects allows you to read the objects from older or newer versions of the
class without changing the database. This is known as on-the-fly versioning, and is extremely useful in
environments where several versions of a class declaration can be in use at the same time. For example,
several programs developed at different times share the same database.
If you want to avoid the overhead of on-the-fly versioning, you can convert the objects to the new format
after you register a class. This can be done using one of the FastObjects administration tools, or by calling
thePtBase::VersAll()method.
FastObjects observes the same rules for on-the-fly versioning and for versioning objects in the database:
• If a new member is added to the class, the objects are initialized to zero.
• If a member is deleted from the class, the objects are removed. If you then store the versioned object or
version the entire database, this data is lost and cannot be recovered.
• If the relative positions of classmembers change, the objects are reformatted to reflect the new positions.
• If the data type, array size, etc. of a member changes and the name remains the same, the old value is
converted to the new type (e.g., a short can be converted to a long).
• Pointers can be changed to ondemand references on-the-fly, or vice versa.
• The type of set can be changed from lset or hset to another set type on-the-fly.

AR>>А почему бы просто не подождать до тех пор, пока они не подгрузятся в кэш по какой-либо иной надобности? А пока просто оставить специальную метку на месте удаленного объекта. Т.е. ссылки редактировать не сразу, а только по мере обращения к соответствующим объектам?

S>Дык, я же именно про это и говорю.

В VDS так оно и есть (описание здесь)

1. Status of deleted — When you delete an object, it is automatically marked for deletion from its database at
the next commit.
2. When an application requests an object, VERSANT first searches the object cache, then the server cache for
the database to which the object belongs, and then the database itself.

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

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

GZ>>Но предполагаю, поскольку это предназначается для ORM, то при удалении будет генерится очень нехилый select или набор select'ов для проверки как возможности удаления, так и для удаления связанных.
S>Ну, вот RDBMS например этого почему-то не боятся.
А вот программеры боятся. Каждая вторая база не удаляет ничего. Возьми хотя бы RSDN для примера. А все потому, что логика сложная получается.
S>Delete всегда проверяет все foreign key. И ничего — вроде как-то живет. В основном благодаря тому, что FK — это всегда индекс; а также потому, что этих FK редко бывает много. Ну сослались на меня из десяти мест — это уже какая-то экзотика пошла.
S>Правда, в OODBMS тут есть некоторая тонкость, связанная с более слабой типизацией. В RDBMS у нас FK всегда попадает ровно в одну таблицу, а стало быть и в обратную сторону связей будет немного. А в ODBMS у нас ссылка может указывать на любого потомка. Так что это может привести к увеличению области сканирования: при использовании везде ссылок на System.Object придется при каждом удалении проверять абсолютно все ссылочные поля!
При удалении System.Object всегда можно определить его действительный тип. Это сократит количество задействованных ссылок. Но тут есть другое увеличение, в этом может участвовать не один объект а целый граф. Ну например, у нас есть несколько связанных логически удаленных объектов. В некоторых из них есть ссылки которые удерживают этот граф от уничтожения.
S>Без практики применения невозможно сказать, насколько проверка наличия ссылок на себя в типичной OODB дороже, чем в RDB.
GZ>>Возможно здесь подсчет ссылок был бы полезней, если бы не его проблемы и требования того, что ORM можно напустить практически на любую базу.
S>Сам по себе подсчет ссылок — всего лишь кэширование результатов поискового запроса. Этакая денормализация.
Я все больше о ней думаю... Но пока это все только прикидки, когда делать буду (и что получится в результате) пока не знаю.

С уважением, Gleb.

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

GZ>А вот программеры боятся. Каждая вторая база не удаляет ничего. Возьми хотя бы RSDN для примера. А все потому, что логика сложная получается.
Это не имеет отношения к теме
GZ>При удалении System.Object всегда можно определить его действительный тип. Это сократит количество задействованных ссылок.
Нет, ты ошибаешься.
Представь себе, что у меня в системе 10 классов. В каждом определено от 1 до 3 ссылок типа System.Object. В средем это получается по 2 ссылки на объект.
Итак, допустим у меня есть миллион этих объектов.
Я пытаюсь удалить один из них.
Независимо от того, какого он типа, на него может указывать любая из двух миллионов ссылок, разбросанных по 12 экстентам. Поэтому нам придется выполнить сканирование двенадцати ращличных индексов для проверки, нет ли там нас.
GZ>Но тут есть другое увеличение, в этом может участвовать не один объект а целый граф.
Верно подмечено. Дорогостоящая операция может получиться.
GZ>Я все больше о ней думаю... Но пока это все только прикидки, когда делать буду (и что получится в результате) пока не знаю.
Ну, статьи про GC в OODB в сети вроде имеются... Дойдут руки — будем почитать

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


S>Независимо от того, какого он типа, на него может указывать любая из двух миллионов ссылок, разбросанных по 12 экстентам. Поэтому нам придется выполнить сканирование двенадцати ращличных индексов для проверки, нет ли там нас.
А кто мешает организовать аналог FK для OODB ????

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

S>Представь себе, что у меня в системе 10 классов. В каждом определено от 1 до 3 ссылок типа System.Object. В средем это получается по 2 ссылки на объект.
S>Итак, допустим у меня есть миллион этих объектов.
S>Я пытаюсь удалить один из них.
S>Независимо от того, какого он типа, на него может указывать любая из двух миллионов ссылок, разбросанных по 12 экстентам. Поэтому нам придется выполнить сканирование двенадцати ращличных индексов для проверки, нет ли там нас.

Имхо, когда речь идет о двунаправленных связях, я бы задумался о хранении при объекте информации о том, кто на него ссылается.

Здравствуйте, Serginio1, Вы писали:
S> А кто мешает организовать аналог FK для OODB ????
Гм. Никто не мешает. Мы про него и говорим.
Попробую повториться еще раз: В RDBMS нельзя сделать ссылку "на что угодно". Она может ссылаться только в конкретную таблицу. Благодаря этому можно ожидать разумного среднего количества кандидатов в обратные ссылки. В OODBMS ссылка может быть полиморфной. Это может привести к деградации производительности при динамическом подсчете обратных ссылок, принятом в RDB.
З.Ы. Все это — теория. Степень "актуального полиморфизма", которая определяет эту "нечеткость" области значения ссылки, зависит от конкретной OODB.

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

S>Здравствуйте, Serginio1, Вы писали:
S>> А кто мешает организовать аналог FK для OODB ????
S>Гм. Никто не мешает. Мы про него и говорим.
S>Попробую повториться еще раз: В RDBMS нельзя сделать ссылку "на что угодно". Она может ссылаться только в конкретную таблицу. Благодаря этому можно ожидать разумного среднего количества кандидатов в обратные ссылки. В OODBMS ссылка может быть полиморфной. Это может привести к деградации производительности при динамическом подсчете обратных ссылок, принятом в RDB.
S>З.Ы. Все это — теория. Степень "актуального полиморфизма", которая определяет эту "нечеткость" области значения ссылки, зависит от конкретной OODB.

Сделать можно, только разруливать придется на клиенте или через дополнительные таблицы к каждому типу обрабатываемые через триггеры в зависимости от типа.
Опять же опыт 1С. Строятся дополнительные таблицы. (правда поиск там ссылочной целосности идет полным сканированием по метаданным).
Для OODB будет зависеть от реализации, там выбор действий намного больше.

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

S>Гм. Никто не мешает. Мы про него и говорим.
S>Попробую повториться еще раз: В RDBMS нельзя сделать ссылку "на что угодно". Она может ссылаться только в конкретную таблицу. Благодаря этому можно ожидать разумного среднего количества кандидатов в обратные ссылки. В OODBMS ссылка может быть полиморфной. Это может привести к деградации производительности при динамическом подсчете обратных ссылок, принятом в RDB.
S>З.Ы. Все это — теория. Степень "актуального полиморфизма", которая определяет эту "нечеткость" области значения ссылки, зависит от конкретной OODB.
Однако тут есть некоторое дополнение. Поскольку ссылка содержит oid экземпляра объекта, то на полиморфизм можно положить. Если ее проверять навигационным способом, то это не должно занимать много времени (у нас проверка объекта — это время на доступ по хешу, и нам в принципе нужно узнавать, есть объект или его нет). Но правда это верно только для двунаправленной связи. Возможно, можно даже запретить подобную ссылочную целостность для недвунаправленной связи как сверхтормозную.

С уважением, Gleb.

На усмотрение модераторов:

29 апреля 2005 г. Компания Ленвендо проводит семинар "Современные технологии сохраняемости Java и .NET объектов";

Дата проведения семинара: 29 апреля 2005 г.

План семинара:

— Обзор современных технологий сохраняемости
— Обзор существующих решений
— ООСУБД – прозрачная сохраняемость объектов
— Системы масштаба предприятия, построенные с использованием технологий ООСУБД
— Инструментарий объектно-реляционного отображения (O/R Mapping Tools)
— Versant Open Access JDO <BR>- Versant Open Access .NET
— Системы масштаба предприятия, построенные с использованием технологий объектно-реляционного отображения

Место проведения:

Санкт-Петербург, Измайловский пр., дом 14 (вход с 7-ой Красноармейской)

Участие:

Участие в семинаре бесплатное

Регистрация:

Зарегистрироваться

Подробнее

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

S> Опять же для Б+ деревьев при определенном использовании верхнии уровни находятся в кэше процессора, поэтому поиск в них на больших данных оазывается быстрее, чем бинарный поиск в массиве с проинлайнниным компаратором, в отличие от компараторов Б+ (TLSD).

Интересный аргумент, и наверняка он неплохо работает в задачах многократного циклического поиска по одной и той же таблице.

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

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

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

Насколько я понял, IMasterDetailLink у вас — это дескриптор для ассоциации (так же как и IEntityDescriptor — дескриптор для ентити)? Так?

Интересно, как именно он реализован внутри!

В каком формате в кэше храняться связи.
Как работают методы IDetailEntitiesCollection.Add и IDetailEntitiesCollection.RemoveChild.
Если есть кэш связей, то какой алгоритм удаления этих связей из кэша.
Какой алгоритм подгрузки связей (вместе с объектами или отдельно).
Какой алгоритм сохранения измененных связей — вместе с объектами или отдельно.
Сколько памяти (в ссотвествии в вашим форматом хранения) в кэше занимает одна связь (не ассоциация целиком, а именно связь).

Насколько ваш формат менее эффективен чем хранение в самих объектах перекрестных ссылок (коллекций ссылок). Т.е. насколько он медленее и почему. И насколько он требует больше памяти.

Как вы отслеживаете ссылочную целостность с учетом изменений (связей), сделанных в кэше.

PS: Понятия ассоциации и связи я использую из UML. Если вы вдруг не в курсе, то там отношение между ассоциацией и связью, аналогичны отношению между классом и объектом. То есть связь, в таком понимании — это instance ассоциации. Это, чтобы нам не запутаться .

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

BZ>В VDS так оно и есть (описание здесь)

BZ>1. Status of deleted — When you delete an object, it is automatically marked for deletion from its database at
BZ>the next commit.
BZ>2. When an application requests an object, VERSANT first searches the object cache, then the server cache for
BZ>the database to which the object belongs, and then the database itself.

Неа. Опять непонятки по теме разговора.

Например, есть два хранимых класса:

class A
{
    List<B> objectsB;
}

class B
{
    A objectA;
}

Например, в базе есть один объект класса A и к нему привязаны 1000000 объектов класса B. То есть a.objectsB.Count == 1000000.
Так как я говорю про двунаправленные связи, то поля objectsB и objectA должны меняться синхронно, то есть если я сделаю:

a.objectsB.Clear();

То это значит, что все objectA у всех соответствующих объектов класса B должны автоматически поменяться на null. Я нигде не говорил про какое-то удаление объектов. При этой операции никакого удаления не проиходит. Объекты класса B не удаляются, просто они перестают быть связанными с объектом 'a'.
Дык, вот если в кэше на момент выполнения Clear() был только объект 'a', то что делать-то, чтобы синхронно изменить поля objectA? Подгружать чтоли все соотвествующие объекты класса B. Или как ?

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

S>Неа. Опять непонятки по теме разговора.

Я немного просто расскажу как это сделано в Versant Developer Suite.

Есть специальный тип BiLink — двунаправленная ссылка. Вот некоторые выдержки из описания.

BiLink and BiLink Vstr Usage

Bi-directional links and bi-directional link vstrs allow creation of links and back links among objects using a single attribute in each of the linked objects. The C++/VERSANT classes that can hold a bi-directional link are:

BiLink<type>
Typed storage of a bi-directional link to another object.

BiLinkVstr<type>
Typed variable length storage of multiple bi-directional links to other objects.


BiLinks — BiLinks are bidirectional forms of the link classes that create bidirectional links between objects that derive from PObject. Like links, bilinks establish object relationships using logical object identifiers stored in a single attribute in each of the linked objects.

BiLinks are defined in the BiLink<type> class. The type parameter specifies the type of the target object. To specify the nature of the back link, you must add a "relationship" statement to the class implementation file. See the section "Creating BiLink and BiLink Vstr Classes" for more information.

BiLink Vstrs — BiLink vstrs are bidirectional forms of the link vstr classes that store multiple bidirectional links between objects that derive from PObject. Like link vstrs, bilink vstrs establish object relationships using logical object identifiers stored in a single attribute in each of the linked objects.

BiLink vstrs are defined in the BiLinkVstr<type> class. The type parameter specifies the type of the target object. To specify the nature of the back link, you must add a "relationship" statement to the class implementation file.

By using bilinks and bilink vstrs, you can create any form of bidirectional relationship among objects. For one-to-one relationships, use bilinks as an attribute in both objects. For one-to-many relationships, use a bilink as an attribute in one object and a bilink vstr as an attribute in the other object. For many-to-many relationships, use bilink vstrs as attribute in both objects.

Following are bilink and bilink vstr usage notes.
• To use bi-directional link and bi-directional link vstr classes, include pobject.h and bilink.h.
• BiLink and bilink vstr attributes should be a public database member of a persistent class.
• BiLink targets must be derived from PObject. Targets of links must derive from PObject. This is because bilinks use the unique logical object identifier that is present only in objects deriving from PObject.
• If a bilink or bilink vstr will point to heterogeneous types, you must supply a type parameter of a base class of all the types involved and cast results downwards as appropriate with the AS() or L_AS() macro.
• Logical object identifiers are not assigned until constructors are finished. This means that it is dangerous to set bilink or bilink vstr attributes in a constructor.
• Whenever you need to use double right angle brackets, such as when a template is used as a type parameter, follow coding guidelines for your compiler. This may mean that you must insert a space between double right angle brackets to avoid them being taken as the right shift operator.
• Virtual methods must be added or redefined indirectly. You cannot directly create or redefine virtual methods in bilink and bilink vstr classes, but you can embed a bilink class, add virtual methods to the class, and then embed the new class in another persistent class.
• BiLink vstrs handle their own memory allocation. Memory used by a bilink vstr is released in the destructor. Thus, there is no release method to handle memory allocation. If a bilink vstr is empty at the time of a commit, then it is automatically deleted.
• BiLink vstrs should not be compared to NULL. Instead bilink vstrs should be tested for being empty by using the is_empty() or size() methods.
• The size of a bilink vstr is part of the persistent state of a bilink vstr object. The size of a bilink vstr is the number of elements that will be saved to or retrieved from a database. The initial size of a bilink vstr is always zero and is changed by adding elements with add() or resizing with set_size().
• If a bi-directional link or bi-directional link vstr contains versioned objects, all objects on each side of the bi-links must be checked out together.
• Two persistent objects may not share the same bilink vstr.
• Setting a forward bilink will automatically set a back link. If you change a bilink from one object to another, existing bilinks will be adjusted.
• If you change a bi-directional link from one object to another, existing bilinks will be adjusted.
• Deleting an object in a bilink or bilink vstr will cause bilinks pointing to that object to be set to null. However, since bilinks provide by-reference semantics, deleting one object in a bilink relationship will not delete the other object. If you want, you can add behavior to your own classes to propagate deletions.
• In general, we recommend that objects that have bilinks or bilink vstrs as attribute types, should not be versioned, because the bi-directional relationship may become inconsistent when updates are made to the bilink or bilink vstr attributes.


Creating BiLink and BiLink Vstr Classes

To create and use the bilink classes BiLink<type> and BiLinkVstr<type>, where type is the class of the target objects, do the following.

1. Include files.

Include both the PObject and BiLink class files in an appropriate class specification file:

#include <cxxcls/pobject.h>
#include <cxxcls/bilink.h>

2. Forward declare the class used in the bilink or bilink vstr.

In a class declaration file .h, declare the type of the objects to be used in the BiLink<type> or BiLinkVstr<type> class.

3. Declare bilink and bilink vstr attributes to be public.

Declare the attributes that will contain the bilink and bilink vstr relationship to be public.

4. Specify the type of relationship.

Specify in a class declaration file .h and implement in a class implementation file .cxx the nature of the bilink relationship: one-to-one, one-to-many, many-to-one, or many-to-many. This is done by using the add() function. Each of the possible ways of using add() returns an integer. If the association succeeds, the return value is 0.

A convenient place to calling an add() function is at the initialization of a static dummy variable.

One BiLink to One BiLink

To establish a one bilink to one bilink relation between class A and class B:
BiLink_to_BiLink<A,B>::add(&A::toB,&B::toA);

One BiLink Vstr to Many BiLinks

To establish a one bilink vstr to many bilinks relation between class A and class B:
BiLinkVstr_to_BiLink<A,B>::add(&A::B_Vstr,&B::toA);

Many BiLinks to One BiLink Vstr

To establish a many bilinks to one bilink vstr relation between class A and class B:
BiLink_to_BiLinkVstr<A,B>::add(&A::toB,&B::A_Vstr);

Many BiLink Vstrs to Many BiLink Vstrs

To establish a many bilink vstrs to many bilink vstrs relation between class A and class B:
BiLinkVstr_to_BiLinkVstr<A,B>::add(&A::B_Vstr,&B::A_Vstr);


The add() function establishes bilink relations at run-time.
For each bilink relation, at least one of the the above template functions should be called before any use of the bilink relation.
For example, to define bilinks and their relations, first define the bilinks:

class B; // mandatory forward declaration
class A: public PObject {
public:
   BiLink<B> toB; // attribute must be public
   BiLinkVstr<B> B_Vstr; // attribute must be public
   ...
};

class B: public PObject {
public:
   BiLink<A> toA; // attribute must be public
   BiLinkVstr<A> A_Vstr; // attribute must be public
   ...
};

Next, add an association initialization statement for each relation to one of the application's .cxx
files.

For this example, a one-to-one link connects toB with toA, and a many-to-many link connects B_Vstr to A_Vstr. You can call the add() function in the initialization of static dummy variables:

static int dummy1 =
   BiLink_to_BiLink<A,B>::add(&A::toB,&B::toA);
static int dummy2 =
   BiLinkVstr_to_BiLinkVstr<A,B>::add(&A::B_Vstr,&B::A_Vstr);

...


Таким образом в VDS двунаправленные ссылки фактически являются отдельными объектами, которые имеют структуру списка в случае one-to-many ссылок. А сами объекты с атрибутами-двунаправленными ссылками фактически содержат ссылки на объекты BiLink или на конкретные элементы списка внутри объекта BiLink. Удаление и редактирование основных объектов-контейнеров приводит к поднятию соответствующего объекта BiLink и проведению с ним неких манипуляций. Но при этом второй (множество) связанный с ним по двунаправленной ссылке объект не затрагивается — изменяются только объекты BiLink.

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

AR>Таким образом в VDS двунаправленные ссылки фактически являются отдельными объектами, которые имеют структуру списка в случае one-to-many ссылок. А сами объекты с атрибутами-двунаправленными ссылками фактически содержат ссылки на объекты BiLink или на конкретные элементы списка внутри объекта BiLink. Удаление и редактирование основных объектов-контейнеров приводит к поднятию соответствующего объекта BiLink и проведению с ним неких манипуляций.

Во-во. "редактирование основных объектов-контейнеров приводит к поднятию соответствующего объекта BiLink" — Это как? То есть соотвествующие объекты (PObject) с другой стороны будут подгружены или нет. Чего-то непонятно написано.

AR>Но при этом второй (множество) связанный с ним по двунаправленной ссылке объект не затрагивается — изменяются только объекты BiLink.

Это как? Объект BiLink является же полем (т.е. частью состояния) хранимого объекта.

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

S>Во-во. "редактирование основных объектов-контейнеров приводит к поднятию соответствующего объекта BiLink" — Это как? То есть соотвествующие объекты (PObject) с другой стороны будут подгружены или нет. Чего-то непонятно написано.

AR>>Но при этом второй (множество) связанный с ним по двунаправленной ссылке объект не затрагивается — изменяются только объекты BiLink.

S>Это как? Объект BiLink является же полем (т.е. частью состояния) хранимого объекта.

Я понимаю так, что здесь мы имеем дело с требя объектами. Два связанных объекта и объект-связь BiLink между ними.

A -> BiLink <- B

Всякий раз делая что-то с объектами A или B (удаляя или редактируя параметры связи) мы поднимаем объект BiLink (но не объект на другом конце связи). В случае one-to-many это выглядит так:

BiLinkVstr <- B
|
A1 -> BiLink -|
A2 -> BiLink -|
A3 -> BiLink -|
... ...

и для many-to many:

BiLinkVstr
A1 -> BiLink -| |- BiLink <- B1
A2 -> BiLink -| |- BiLink <- B2
A3 -> BiLink -| |- BiLink <- B3
... ... ... ...

Причем объекты BiLink являются частью объекта BiLinkVstr (элементами коллекции).

Впрочем, я не такой уж эксперт по VDS и могу ошибаться. Пусть BaZa меня поправит, если это так.