U-geneЯ не очень Ваши вопросы понимаю. На то, что понял, пытаюсь ответить.
[...]
Спасибо за ответы.
U-geneНет не так.
(Клиент + API-доступа) -> (SQL+RxO расширения) -> (БД)
Одним словом, своим уточнением сути концепции RxO Вы расставили многие вещи по своим местам (имею в виду, в моей голове). Да, в Ваших демо-материалах есть общие изложения на счёт "расширения реляционных СУБД" и т.д., но по прототипу складывалось впечатление, что это некая замкнутая система, или какая-то подсистема внутри (или точнее, над) SQL. Где кроме классов ничего нет. Вы писали о том, что собираетесь скоро добавить "таблицы", о которых тоже складывалось впечатление как об ещё одной абстракции над исходными sql-таблицами. Видимо, косвенно сказывается функционал самого прототипа и имеющийся набор демо-примеров, т.е. что пока есть, то и есть (извините, но пока имеющееся всю суть наглядно не отображает, в общем, дело времени, и это очевидно). И моя беда в том, что я и пытался моделировать именно в этой замкнутой системе, и, естественно, ничего толком так и не смог сделать ("виртуально" удовлетворить своих тараканов).
В т.ч. Вы показали, что готовите (потенциально) полный стек технологии, включая функционал и для "клиентов". Ведь результат RxO-запроса - те же табличные данные, которые нужно как-то обрабатывать. Для этого, кому нужен "Object-to-Object Mapping", возможно применение соответствующих stub-классов.
Надеюсь, что наконец-то, всё правильно понял.
Уточню на счёт "логического-физического". Я не буду обращаться в сторону "концептуальных моделей" и "моделей данных", поскольку здесь в теме форума есть момент несогласованного их взаимопонимания сути, поэтому лучше проведу аналогию с типовыми case-средствами. Они имеют схемы данных, через которые могут отражать логические модели и физические, при этом, ER-сущности могут не всегда тождественно отображаться на физическом уровне (на уровне таблиц и т.д.). Конечно, сравнение условное, т.к. RxO-классы есть уже некая сущность более высокого уровня (грубо, та же "шапка" и "строки" накладной соединяются в одно целое). С понимаем концепции, вроде проблем нет, а вот была проблема с "реализацией" классов ("виртуальной"), чтобы можно было организовать любое нужное физическое хранение (из-за "замкнутой" системы).
Отсюда есть нюансы. Для полной гармонии в "реализации" классов не хватает сокрытия операций создания объекта ("оператор NEW") и операций модификации с удалением (что, кстати, в моём случае, отчасти, тоже было важным недостающим звеном, без которого никак, чтобы причесать прикладную модель). Имеющиеся методы в классах есть методы именно объектов, т.е. если посмотреть на пример:
1.
2.
3.
4.
5.
6.
7.
8.
ALTER DOCS REALIZE DoShip(inDate DATETIME) AS
BEGIN
IF(Date IS NULL) THEN
BEGIN
Date := inDate;
Comment := "Shipped!";
END
END
то заметим, что здесь есть обращение к свойствам "текущего" объекта (имхо, так проще назвать). Короче говоря, нужны какие-то "статические" методы (или методы класса) для манипуляции "над объектами" (для осуществления CRUD-операций). Собственно, подозреваю, что нет причин их не реализовать (ну, также нужен явный запрет/разрешение операций а-ля "grant" и т.п., но, очевидно, что обсуждать здесь нечего, однозначно, всё будет на борту).
Далее, по поводу возможных проблем с наследованием. Из-за того, что вопросы на счёт "замкнутости" системы уже разрешились, то и ряд затронутых ранее мной проблем также прояснились (для меня). Но, всё таки, есть нюансы. Глянем опять же на те же документы (раз уж я к ним прицепился):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
CREATE CLASS Документы
(
Номер STRING,
Дата DATETIME,
Поставщик INTEGER,
Количество NUMERIC,
Сумма CURRENCY,
...
Содержимое SET OF
(
Товар INTEGER,
Количество NUMERIC,
Цена CURRENCY,
Сумма CURRENCY,
...
);
);
ALTER Документы REALIZE (Номер, Дата, ...) AS STORED.
Какой-то разработчик, реализующий обработку "общих" документов, где-то закладывает RxO-запрос для выборки а-ля:
SELECT ... FROM Документы WHERE ...
Модуль завершен, проведены все проверки, инсталяция работает в сотнях мест. Затем другой разработчик где-то реализует новый класс потомок:
CREATE CLASS Накладные EXTEND Документы
(
);
И по каким-то причинам делает "реализацию" класса так, что теперь "Количество", "Сумма" не являются хранимыми, а теперь вычисляются через запрос к "строкам" а-ля:
ALTER Накладные REALIZE (Количество, Сумма, ...) AS select ... sum(.Содержимое.Количество) ... from .Содержимое
Здесь, с учётом того, что сказано в
14408866 (о том, что класс отображается в свою таблицу), я могу предположить, что для "документов" и "накладных" (в т.ч. и для "Содержимого") внутри БД будут созданы соответствующие таблицы. И нужно понимать, как будет теперь транслятор выполнять свою работу при выборке из общих документов:
SELECT ... FROM Документы
Т.е. RxO-запрос м.б. преобразован в SQL вида:
SELECT ... FROM Документы UNION SELECT ... FROM Накладные
где, например, в части выборки из "накладных" через подзапрос будут вычисляться "количество", "сумма" из "содержимого" (т.е. текст sql-запроса будет сформирован на основе RxO-запроса, указанного в "ALTER Накладные REALIZE ..." выше). Или же, например, таблица "накладные" будет создана со столбцами "Количество", "Сумма", для которых будут заданы вычислимые выражения через "computed by". Или же как только где-то в коде будет встречено выражение вида ".Количество", т.е. обращение к соответствующему свойству объекта "накладные", то это вызовет выполнение запроса (или его части, если такое возможно) из "ALTER Накладные REALIZE ...".
Пока нет точных сведений как работает транслятор. Но суть не в технических реализациях. Я о том, что работу того, кто пахал над "общими документами", фактически, как бы полностью переделали. При этом, тот кто реализовал класс-наследник "накладные", даже понятие не имеет (и, теоретически, и не должен) как устроен внутри базовый функционал в классе-предке (или во внешнем функционале, оперирующем "общими документами"). Если бы трудяга над классом "Документы" изначально бы закладывался на потребность извлекать данные из "содержимого" документов, то он бы возможно совсем по-другому реализовывал бы нужный функционал.
Такие неожиданности не есть глобальная проблема, это естественные особенности применения целевой системы абстракции, которые должны настораживать, как минимум.
Далее, на счёт "зацикливаний". Возьмём два класса:
класс А
класс B
Это независимые классы, некие базовые заготовки. Появляется новый класс С, потомок от А, где внутри "реализации", т.е. в выражении "ALTER <class> REALIZE ...", имеется RxO-запрос для выборки данных из класса B. Назову подобный запрос через "использует", для краткости в дальнейшем, и буду говорить, что класс С "использует" класс B. В итоге:
класс А -> класс С "использует" B
класс B
Появляется ещё один класс D, потомок от B, который в свою очередь "использует" класс A:
класс А -> класс С "использует" B
класс B -> класс D "использует" A
Разработчики классов С и D могут друг о друге и не знать, соответственно и не подозревать о существовании "соседнего" класса в системе (условно). И, например, при выборке данных из класса А автоматом сработает "realize" в потомке С, что вызовет "обращение" к B, а далее через потомка D вновь "обращаемся" к A.
Конечно, это очевидные вещи, и в том же SQL "зацикливания" вполне возможны. Но, в отличие от "SQL", в рамках RxO имеется дополнительная связь -"наследование", т.е. в дополнение к базовым "объект используется там-то" и "объект использует это" есть и дополнительные связи "предки-потомки", причём которые дают "автоматический вызов" кода (так, что-ли). Учитывая специфику ООП, когда иерархия растёт вертикально и горизонтально (количество потомков на одном уровне), эти связи расширяются довольно не слабо таки. Конечно же, далеко не каждый класс будет содержать опасные места.
Надуманные ли все выше обозначенные проблемы - сомневаюсь, особенно учитывая реальные промышленные проекты с немалым количеством мета-объектов в БД, причём ведь взаимосвязанных. Мне кажется, что подобные проблемы можно как-то контролировать, но в пределах локализованного модуля (а-ля sql-пакета). И вполне, возможно, есть не надуманная потребность ограничить "наследование" в пределах модуля, т.е. не разрешать наследоваться от "внешних" классов. Но это означает и ограничение применения классов (лично я не рискнул бы выпускать "наследование" в опасное бесконтрольное путешествие, и уточню, что это моё личное мнение и только для себя, ничего не кому не навязываю).
И по поводу "полной компиляции". С ней тоже вопросы решились. Но не все. Поскольку уже известно, что RxO гармонично находится внутри SQL-СУБД, то RxO-система должна отвечать и её требованиям. В частности, при выполнении оператора "ALTER <class> REALIZE ..." (и реализация "методов") должны быть установлены все зависимые связи с объектами, т.е. оператор "REALIZE" должен восприниматься как аналог "create or alter/replace procedure ..." в SQL, где для процедуры в метаданных будут прописаны все используемые объекты. Потенциал для этого зависит от принципов работы транслятора, особенно с учётом "наследования", поскольку есть подозрение, что в общем случае, все запросы внутри "реализаций" сразу не попадают в виде SQL непосредственно в СУБД (и она должна устанавливать связи), они "откладываются", и уже во время конкретных операций собирается вся цепочка по иерархии. Повторюсь, это лишь мои подозрения.
Если бы в двух словах концептуально как работает транслятор (на примере тех же "документов выше", т.е. при "наследовании", да плюс вызов метода класса) - стало бы всё ясно с этим вопросом.
*** Уточню, перед тем как публиковать этот пост я заметил, что Вы дали ссылку на документик на счёт "трансляции". Очень быстро посмотрел, пока сплошная "математика", нужно по детальнее посмотреть, возможно разберусь.
Собственно, это основное, что я был обязан выразить более вменяемо. Надеюсь, что получилось.
P.S. На всякий случай, прошу извинить, если мой предыдущий пост имел некую эмоциональную окраску (что, скорее всего, так и есть). В любом случае, это были общие эмоции из-за окружавшей обстановки (на счёт РСУБД, ошибок природы и т.д.), не направлены ни в какую сторону. В свою очередь, я прекрасно понимаю, что приведенные мной Ваши цитаты в том же посте тоже есть продукт такого же эмоционального общения (причём, вынужденного), это очевидно.
