Конкретные вопросы по lsFusion. Часть 2.

В этой ветке только вопросы по lsFusion, без оценок и срача, что в сторону lsFusion, что в сторону 1С.

Для сравнения и троллинга есть отдельная ветка : OFF: lsFusion vs 1C. Раунд 3

(525) Несколько картинок :
CLASS Image;
sku = DATA Sku (Image) NONULL DELETE;
file = DATA IMAGEFILE (Image);

Прикрепление к строке документа :
image = DATA IMAGEFILE (DocumentLine);

(527) Смотрите, IMAGEFILE - это просто примитивный тип. Вроде строки. В базе данных она хранится как byte array (то есть просто бинарным файлом). Соответственно просто в строке появляется новое поле. Как правило, мы складываем их в отдельную таблицу, чтобы не раздувать основную таблицу со строками :

TABLE documentLineImage(DocumentLine);
image = DATA IMAGEFILE (DocumentLine) TABLE documentLineImage;

К сожалению, оптимизация получилась не полной. В общем случае FOR может скомпилироваться в один SQL запрос (а не выполняться на сервере приложений), если в нем нет IF'ов, других FOR'ов и строки записи внутри его не зависят друг от друга. У Вас же получается, что внутри пробега создаются группы, производители и прочие. Для оптимизации нужно вынести создание справочников за пределы FOR'а.

Например, с импортом групп снаружи FOR будет другой цикл по созданию несуществующих групп :
FOR [GROUP MAX INTEGER i BY groupName(i)](ISTRING[100] name) AND NOT groupByName(name) NEW g = Group DO {
    name(g) <- name;
}

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

Потом уже при заполнении свойств sku там останется только
group(u) <- groupByName(groupName(i));

так как все группы уже созданы в предыдущем FOR'е.

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

(539) Я тут немного понял вот что, делать вот так вроде как нельзя :
FOR groupName(INTEGER i) AND NOT groupByName(groupName(i)) NEW g = Group DO {
name(g) <- groupName(i)
}

Поскольку, если это не будет скомпилировано в один запрос, то сначала вычисляется выражение, а затем идет по нему итерирование уже на сервере приложений. Так как таблица денормализованна, то создастся несколько групп с одинаковым именем и сохранение не пройдет по CONSTRAINT. Поэтому в моем примере шел GROUP MAX.
В целом важно понимать, что нужно стремиться, чтобы все компилировалось в SQL запрос, так как выполнение на сервере БД значительно быстрее чем round trip между сервером приложений и сервером БД.

[Может, немного сбил синтаксис локальных свойств, что вместо
groupName = DATA LOCAL ISTRING[100] (INTEGER);
нужно писать
LOCAL groupName = ISTRING[100] (INTEGER);]
Эти два объявления с точки зрения выполнения идентичны. Разница в том, что второе объявление видно только в пределах действия, а первое - в пределах модуля и зависимых от него модулей.

[С INLINE мне не совсем понятно. Есть ли небольшое ускорение, или и без INLINE компилятор нормально справился в данном случае.]
Итерирование на большом объеме в любом случае медленнее, если с INLINE они одинаковы, то или INLINE не сработал и запрос не скомпилировался, или наоборот, исходный скомпилировался. Вообще, с точки зрения выполнения это хорошо видно по "бегунку" в GUI. При итерировании будет идти бегунок, когда выполняется SQL запрос, то никакого бегунка быть не может, так как SQL запрос не возвращает данные о статусе своего выполнения в данный момент.

[Я бы предпочёл не указывать тип параметра ISTRING[100]].
Да, там можно не указывать. Платформа должна в таком случае вывести тип сама (если получится).

(542) Если речь идет о запуске в Try, то вот модифицированный код, который работает :
REQUIRE Utils; // Моя добавка, т.к. iterate в utils

a = DATA LONG (LONG, LONG);

FORM a
    OBJECTS i1=LONG
    FILTERS iterate(i1,1,10)

    OBJECTS i2=LONG
    PROPERTIES a(i1,i2) COLUMNS (i1) HEADER (i1)
    FILTERS iterate(i2,1,10)
;

NAVIGATOR {
    NEW a;
}