Как вы программно получаете доступ к карте памяти для класса кэша?

Question

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

Когда я компилирую обычный постоянный класс, создается «хранилище», и я хотел бы иметь возможность архивировать некоторый код, который позволил бы мне воссоздать это «старое хранилище», чтобы я мог получить доступ к «старой версии» из глобальный и сопоставить значения в текущее сопоставление класса. У меня есть методы objectgenerator, которые будут сохранять версию с каждой записью и определять, отличается ли «текущая версия» кода класса от версии, сохраненной в самой записи данных, но я не уверен, как сохранить то, что «старый «версия на самом деле выглядела так, что я могу автоматически переносить данные из« старого в новое ». Чтобы сделать это, я думаю, что, имея возможность читать текущее хранилище во время компиляции, я должен сохранить это значение в другом месте и создать прочный «читатель версии», чтобы я мог переносить данные вперед, не имея на самом деле попросите программиста выполнить эту работу.

Это похоже на разумный подход? и если да, может ли кто-нибудь указать мне, где, во время компиляции, значения хранилища, я могу сделать сохранение данных?

(или я должен смотреть на клонирование какой-то части генерироваться% Save() метод цепи во время компиляции версии определенной экономии прилагается к «что-то другое» (не уверены, что, но «что-то»))

Этот вопрос и ответы изначально возникли в Сообществе разработчиков InterSystems https://community.intersystems.com/post/how-do-you-access-storage-map-cache-class-programmatically

Answer 1

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

1. Простейший и лучший способ перехода от одной версии класса к следующей - сохранить такое же определение хранилища. Компилятор класса создаст слоты для любых новых свойств и полностью неразрушающий и консервативный. Когда я удаляю свойства, я обычно вручную переименовываю слот для хранения и присваиваю ему префикс, такой как zzz. Это позволяет мне явно очистить и повторно использовать эти слоты позже, если я так захочу.

2. Для типа триггеров перед/после компиляции, которые вы ищете, я бы использовал методы RemoveProjection/CreateProjection класса проектирования, которые обеспечивают «способ настройки того, что происходит, когда класс компилируется или удаляется».

3. Вы можете использовать% Dictionary.CompiledStorage и связанные с ним классы (данные), чтобы иметь полный доступ к определению класса скомпилированного хранилища.

3a. Альтернативный подход заключается в использовании анализа XSLT или XML для чтения определения хранилища из определения экспортированного класса. Я бы использовал эту альтернативу только в том случае, если вам нужно собрать данные для отдельных целей контроля источника.

4. Простейшие определения хранения используют слоты $ ListBuild и один глобальный узел. Когда используются подклассы и свойства коллекции, определение хранилища по умолчанию становится более сложным - именно там вы действительно захотите придерживаться простого подхода (пункт 1).