flexberry / rfcs Goto Github PK

При генерации баз геоданных используются типы geometry и geography, производительность которых без индексов очень низкая - создание индексов на эти колонки обязательно. Хорошо бы чтоб скрипты их создания генерировались из метаданных при создании БД. #6

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

Хочу ввести что-то типа «пространства имен», для классов и объектов, из аддонов ember-flexberry..., в генерируемом приложении.

Для контроллеров, роутов, адаптеров, сериалайзеров, моделей, и может чего-то ещё, генерировать в приложении в директорию flexberry, класс, который будут расширять классы приложения.
Это позволит однообразно вносить доработки, необходимые для всего приложения.

Например, для контроллера это должно получиться примерно так:

// app/controllers/flexberry/edit-form.js
import EditFormController from 'ember-flexberry/controllers/edit-form';
export default EditFormController.extend({
});

// app/controllers/application-user-e.js
import EditFormController from './flexberry/edit-form';
export default EditFormController.extend({
});

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

Есть проблема с компонентами, по правилам именования, имя компонента должно содержать минус, при этом директория, в которой находится компонент, не учитывается.
Получается что нельзя создать компонент с именем {{flexberry/file}}, а в имени {{flexberry/flexberry-file}} слишком много flexberry.
В текущей версии ember-cli, используемой в аддонах ember-flexberry..., это правило не валидируется в полном объеме, и можно создать компонент с именем {{flexb-berry/file}} или {{flexberry/-file}}, но не думаю что этим хаком стоит пользоваться.

Нужно сделать пример приложения, которое включает в себя наше типовое приложение и возможности, предоставляемые Apache NiFi по загрузке и трансформации данных (ETL). Пример в конечном итоге должен включать в себя исходный код и файлы Docker и docker-compose, которые позволят любому человеку, имеющему у себя Docker склонировать репозиторий и запустить проект. Посмотреть в браузере как всё работает.

Суть примера такая: есть некоторая предметная область, которая реализована в обычном нормализованном варианте (OLTP). Для эмуляции работы пользователей реализована кнопка заполнения БД данными (логику взять из реализации задачи про Apache SuperSet, если там будет готово раньше, либо поделиться с ним). Также есть БД в ClickHouse с денормализованной структурой. ETL нужен для настройки механизма преобразования и синхронизации данных между OLTP и аналитическим хранилищем.

В качестве примера можно смотреть на решение задачи по Apache SuperSet.

• Спроектировать тестовое приложение в Flexberry Designer Online, назвать NiFiSample. Попросить ту же модель, что в задаче про SuperSet, но добавить отдельно плоскую таблицу, которая будет использоваться в качестве аналитической. Эта плоская таблица должна содержать данные всех остальных классов в денормализованном виде.
• Настроить генерацию, которая включает в себя Postgres и Clickhouse.
• Сгенерировать тестовое приложение в песочницу и форкнуть его в организацию Flexberry (попросить Игоря сделать форк)
• Удалить из SQL-скриптов лишние таблицы (из Postgres денормализованную таблицу, из ClickHouse оставить только её)
• Реализовать функцию наполнения данными приложения (взять из примера про Apache SuperSet).
• В тестовом приложении создать файлы Docker и docker-compose для запуска примера в одном стеке с Apache NiFi
• Создать Readme.md с описанием реализованного примера, ссылками на базовую страницу проекта, документацию и другие полезные материалы
• Настроить NiFi для преобразования данных, которые появляются в OLTP-хранилище так, чтобы данные автоматически подгружались в ненормализованную БД ClickHouse.
• Добавить сервис с Apache SuperSet, который будет настроен на ClickHouse (см. соответствующий пример). Настроить дашборд, который будет показывать, что данные успешно попадают из OLTP в аналитику.

В DataService требуется реализовать следующие дополнительные методы:

• Выполнение операций над хранилищем в async / await стиле (асинхронность вплоть до вызова ADO.NET).
• Типизированные generic-методы для работы с прикладными объектами данных. При чтении удобно получить List<ПрикладнойТип>, а не DataObject[].
• Для работы с детейлами заменить DetailArrayOf на что-то более современное.