lsFusion corporate blog
Open source
Programming
Interfaces
ERP-systems
Comments 4
0
Спасибо за интересную статью.

БД в вашей архитектуре берет на себя нагрузку по хранению данных и метаданных, обеспечению ссылочной целостности, рендерингу страниц, согласно метаданным.
Т.е. несколько слоев завязаны на БД.
Вопросы по БД:
  1. Как справляется базка при большой нагрузке?
  2. Реализовано ли кэширование данных для снижения нагрузки?
  3. Есть ли разграничение прав доступа при формировании запросов к БД?
  4. Есть ли защита от дурака, когда некорректный JOIN или DELETE без фильтра может «положить» среду?


Вопросы по базовым компонентам и среде:
  1. Можно-ли расширять список базовых компонентов?
  2. Можно-ли расширять список свойств у базовых компонентов?
  3. Можно-ли добавлять кастомный код обработки на клиентской строне (JavaScript)?
  4. Можно-ли добавлять кастомный код обработки на серверной строне, и если да, то какой используется язык?

0
Как справляется базка при большой нагрузке?

Я бы сказал, это одно из самых важных преимуществ платформы. Собственно у нас основные клиенты сейчас — FMCG-сети именно потому, что там большие объемы данных и сложная логика, и там скажем ORM'ы очень плохо выживают.
Реализовано ли кэширование данных для снижения нагрузки?

Кэшируется все, что связано с изменениями в сессии. Сами данные базы не кэшируются а) за это отвечают всякие shared buffers в самих СУБД, б) непонятно как ACID (в частности MVCC) поддерживать
Есть ли разграничение прав доступа при формировании запросов к БД?

Политика безопасности поддерживается на уровне платформы. Там много разных настроек, на уровне СУБД пока ничего не проверяется, если вы об этом. И если честно не совсем понятно зачем это делать.
Есть ли защита от дурака, когда некорректный JOIN или DELETE без фильтра может «положить» среду?

Напрямую к базе никто запросы не формирует. Другое дело, что никто не запретит написать invoice(InvoiceDetail id) < — NULL. Но обычно в сложных логиках существует вагон ограничений и шансов что такое действие выполнится 0. Да, теоретически запрос может повиснуть, но это обычно приводит к тому, что одно ядро проца забивается, но не более. Но для всего этого есть монитор процессов где видны все залипшие запросы и это очень быстро диагностируется.
Можно-ли расширять список базовых компонентов?

Пока нет, так как поддерживается и десктоп и веб-клиент, и непонятно даже на каком языке это делать. Но вообще в следующей версии скорее всего перейдем на схему с генерацией реакта и там можно будет любые базовые компоненты Reacta добавлять.
Можно-ли расширять список свойств у базовых компонентов?

Честно говоря не до конца понял вопрос. Но возможно в контексте предыдущего ответа это не актуально.
Можно-ли добавлять кастомный код обработки на клиентской строне (JavaScript)?

Как ни парадоксально, но наоборот можно только в десктоп-клиенте на Java (добавляется этот код все равно на сервер, где класс сериализуется, пересылается на десктоп-клиента и там выполняется). Но даже в этом случае идеологически не предполагается прямого изменения компоненты (этот код в основном используется для работы с оборудованием), предполагается, что все работает через реактивность как в React. То есть данные изменяются на сервере, клиент это чисто рендерер и генератор событий.
Можно-ли добавлять кастомный код обработки на серверной строне, и если да, то какой используется язык?

Да, естественно, Java. Создается Java-класс MyAction, дальше регистрируется myAction INTERNAL 'my.java.MyAction'; и этот action выполняется как будто он на lsFusion написан. Ну и через DI можно на сервере приложений инстанцировать свои объекты (например сервера какие-нибудь).
0
Спасибо за ответы.

>> Можно-ли расширять список свойств у базовых компонентов?
> Честно говоря не до конца понял вопрос.
> Но возможно в контексте предыдущего ответа это не актуально.
Может быть и актуально: если UI генерится через метаданные и есть логическое разделение между метаданными и базовыми элементами, которые отрабатывают переданные им настройки, то можно расширять фукнционал базовых элементов путем расширения метаданных и обработки доп. свойст на стороне базовых элементов.

>> Можно-ли добавлять кастомный код обработки на серверной строне, и если да, то какой используется язык?
> Да, естественно, Java.
Помимо Action, есть ли возможность «врезаться» в базову логику ядра?
Т.е. добавить кастомную логику в события ядра системы.
Например, стандартный обработчик изменения данных по сабмиту формы — событие изменение данных, перед сохранением: перед сохранением нужно сделать проверку на имя таблицы и сделать доп. инициализацию некоторых полей перед записью в таблицу.
Такое возможно?
0
Может быть и актуально: если UI генерится через метаданные и есть логическое разделение между метаданными и базовыми элементами, которые отрабатывают переданные им настройки, то можно расширять фукнционал базовых элементов путем расширения метаданных и обработки доп. свойст на стороне базовых элементов.

UI генерится через метаданные, но логического разделения между базовыми элементами как такового нет: а) для упрощения разработки, б) так как там как минимум 2 вида клиента один на Java, второй на JavaScript (фактически он на самом деле тоже на Java который через Gwt компайлится в JavaScript).

Это разделение возникнет при добавлении React схемы (описанной в статье), когда платформа будет генерить React-дизайн, который потом можно менять (по аналогии с отчетами). Но даже в этом случае логично с дополнительными «настройкам» работать как с данными. Например как сейчас в отчетах, надо сделать выделение цветом, просто делается свойство на форме background = IF smth(a) THEN RGB(4,3,5) ELSE RGB(12,4,5) и дальше этот background можно использовать в самом отчете (jrxml).
Помимо Action, есть ли возможность «врезаться» в базову логику ядра?
Т.е. добавить кастомную логику в события ядра системы.
Например, стандартный обработчик изменения данных по сабмиту формы — событие изменение данных, перед сохранением: перед сохранением нужно сделать проверку на имя таблицы и сделать доп. инициализацию некоторых полей перед записью в таблицу.
Такое возможно?

Есть набор стандартных событий, в том числе и ON OK:
EVENTS
    ON OK { posted(i) <- TRUE; }, // указываем, что при нажатии пользователем OK должно выполняться действия, которое выполнит действия по "проведению" данного инвойса

С добавлением своих событий, такая же ситуация как и с добавлением своих базовых компонент (в React'е все что угодно, в текущей схеме непонятно где и на каком языке). Хотя никто не мешает fork'уть репозитарий и добавить любое событие — собственно после этого mvn clean package -P assemble и можно после этого использовать свою jar вместо jar с центральных репозитариев. Но это уже конечно хардкор.

Only those users with full accounts are able to leave comments. , please.