Есть возможность выгрузить схемы целиком в архив, где вся схема в YAML, а весь код -- в отдельных файлах. Потом её можно загрузить назад. Вот тут подробнее: https://wiki.ozma.io/ru/administration/save_restore. Страница сохранения-загрузки пока прикручена сбоку ¯\(ツ)/¯ Ну и по API можно дёргать, у нас партнёр написал себе скрипты для деплоя в одну команду.
В будущем хотим сделать как раз git, то есть к каждому инстансу привязать репу, которая синкается со схемами в базе. Идея, что свои модули люди смогут выкладывать в открытый доступ на тот же GitHub, и свои собственные мы хотим выложить так же.
Да, INSERT/UPDATE генерятся автоматически. Чтобы делать операции сложнее, чем в триггерах, и в одной транзакции, есть actions. Это примерно хранимые процедуры, но на JS и с нашим API. В них можно передавать произвольные штуки из фронта, и они могут возвращать, например, отображение, на которое после выполнения нужно перейти. Есть ещё несколько идей для похожей гибкости, например, виртуальные таблицы (тоже самое, что VIEW с INSTEAD OF-триггерами в Постгресе).
Про дочернюю таблицу: да, так можно и сейчас всё будет в рамках одной транзакции. Про это мы ещё думаем -- пользователям тяжело работать "транзакционно", они привыкли, что отредактированное просто сразу сохраняется. Видимо, будем делать опциональную панель "Изменения" с кнопкой "Применить", которую можно будет включать атрибутом.
UI:
Нет, "родные" компоненты живут на той же странице. Давать доступ кастомным компонентам ко всему фронту страшно - хочется, чтобы доступ у компонента был только к своим собственным данным.
Да, такие же мысли. Это хочется совместить с некоей "схемой" атрибутов, которая будет проверяться на стороне базы - чтобы ловить опечатки и тому подобные ошибки. Сейчас атрибуты не проверяются никак, кроме как глазами в UI "что всё работает".
Про аудиторию: кроме MVP хочется попробовать стать и платформой для разработки бизнес-приложений. Предположение, что наша гибкость даёт возможность реализовывать сложные проекты, а цена разработки и лицензии при этом ниже, чем у гигантов навроде MS CRM. Проблему с техническим порогом вхождения стараемся решать близостью FunQL к SQL, и использованием стандартного JS в остальных местах. И ищем вендоров, которым интересно нас внедрять, чтобы внедряли не сами компании.
Наконец, ещё думаем про себя как про возможную платформу для приложений: на базе нас можно реализовывать свои сервисы, и писать к ним свой интерфейс.
Согласен, про язык можно было рассказать чуть больше. Попробую это сделать здесь.
Если кратко: свой язык делался потому что чесалось для скорости и удобства разработки. Были сначала мысли как-то на уровне определения явно разделять данные и отображение. Например, запросы писать на чистом pgSQL, а атрибуты для отображения задавать отдельно формулами (тоже на pgSQL). В итоге оказалось, что писать запросы так неудобно - формат, когда прямо в запросе есть атрибуты, разработчику решений позволяет работать эффективнее.
Потом язык уже оброс своими фичами, которые специфичны для базы: например, оператор =>, который позволяет обходиться без JOIN, и операции с наследованием таблиц (которое у нас реализовано по-другому, чем в самом PostgreSQL). При этом мы стараемся держаться максимально близко к изначальному SQL - он зачастую хорошо известен целевой аудитории продукта, разработчикам (даже начинающим) бизнес-приложений. Хочется, чтобы они могли понять идею атрибутов за пару часов и уже эффективно работать.
При этом абсолютно верно, что данные и отображение мешать - это в целом плохой тон, и мы тут именно что рисуем GUI на SQL. Тут две мысли. Во-первых, на практике для большинства форм и таблиц это кажется приемлемым решением, потому что "логики" в запросе, как таковой, почти нет -- если убрать все атрибуты, то это простой SELECT с возможными WHERE по нескольким параметрам, и с ORDER BY, который скорее уже часть отображения. Такие запросы составляют большую часть разработки бизнес-приложений.
Во-вторых, мы хотим реализовать вызов user view (они же как функции) изнутри других user view, и написать гайдлайн, в котором будем советовать для любых нетривиальных запросов разделять так данные и отображение. Условно, один сложный запрос без атрибутов, и один или несколько, которые делают простой SELECT из него и только добавляют нужных опций (или дополнительно его фильтруют, скажем). Это всё в планах.
Про ЯП общего назначения: не хотелось давать возможность писать произвольный код внутри запроса. SQL тут хорош как раз тем, что он (в изначальном виде) только про данные. Все атрибуты у нас, как и сам результат запроса, декларативны - это либо значения, либо формулы. Поэтому в итоге выходит, что весь UI задан набором таких значений и формул. Это, с одной стороны, ограничивает разработчика (можно было бы дать возможность, скажем, писать UI на JS, и разрешить вообще что угодно). С другой -- для большинства отображений это повышает скорость разработки и читаемость кода. Например. SELECT balance @{ cell_color = CASE WHEN balance < 0 THEN 'red' ELSE 'green' } - тут сразу понятно, что выбирается и какая логика раскраски ячеек. Ну и наконец, это позволяет нам гораздо свободнее внедрять различные оптимизации и улучшения в интерфейс, чем если бы возможен был произвольный код на любом уровне.
Про базу. На всякий случай: фронт и базу я тут буду различать, потому что базой можно пользоваться отдельно:
Да, схемы, таблицы и колонки произвольные везде, кроме схемы public и автоматического числового id во все таблицы (его тоже есть планы не требовать, но потом);
Поправьте, если не про то. Логика модификации данных не генерится из SELECTов, а сделана хитрее: в запрос внутри вставляются доп. колонки, и для каждой ячейки из запроса по API возвращается информация, из какой она реально записи. Фронт использует эту информацию, чтобы давать редактировать почти любые поля. Про вмешательство не понял, можно пример?
У базы есть вызов /transaction, куда можно передавать произвольный список изменений. На уровне фронта раньше было явно, сейчас нет - пользователям оказались непонятны явные гранзакции. Про дочернюю таблицу не понял, уточните?
Про интерфейс:
Да, по сути графики из статьи - и есть произвольные контролы на форме. В iframe контрола прилетают данные из ячейки, и есть вызовы, чтобы данные менять;
Расширять нельзя, не придумали пока, как - есть только разные атрибуты для настройки. Новый можно, как в (1);
FunQL и сама база на самом деле вообще не знают, что есть фронт или какая-то логика отображения. По сути это просто SQL-база с добавленными (произвольными) атрибутами, которые можно интерпретировать, как угодно. Фронт же на основании значений атрибутов строит всю страницу.
Перестраивается фронтом после каждого редактирования. Забавный пример: если редактируете "код" редактора кода, то он при сохранении сразу будет меняться.
Да, планируется позже. При этом, скорее всего, в нём нельзя будет собрать совсем произвольный запрос, но всегда можно редактировать код.
Хорошая мысль, потому что кажется, что такое можно сделать отдельно от (5), чуть ли не всплывающее окошко из редактора кода. Подумаем.
Есть возможность выгрузить схемы целиком в архив, где вся схема в YAML, а весь код -- в отдельных файлах. Потом её можно загрузить назад. Вот тут подробнее: https://wiki.ozma.io/ru/administration/save_restore. Страница сохранения-загрузки пока прикручена сбоку ¯\(ツ)/¯ Ну и по API можно дёргать, у нас партнёр написал себе скрипты для деплоя в одну команду.
В будущем хотим сделать как раз git, то есть к каждому инстансу привязать репу, которая синкается со схемами в базе. Идея, что свои модули люди смогут выкладывать в открытый доступ на тот же GitHub, и свои собственные мы хотим выложить так же.
База:
Да, INSERT/UPDATE генерятся автоматически. Чтобы делать операции сложнее, чем в триггерах, и в одной транзакции, есть actions. Это примерно хранимые процедуры, но на JS и с нашим API. В них можно передавать произвольные штуки из фронта, и они могут возвращать, например, отображение, на которое после выполнения нужно перейти. Есть ещё несколько идей для похожей гибкости, например, виртуальные таблицы (тоже самое, что VIEW с INSTEAD OF-триггерами в Постгресе).
Про дочернюю таблицу: да, так можно и сейчас всё будет в рамках одной транзакции. Про это мы ещё думаем -- пользователям тяжело работать "транзакционно", они привыкли, что отредактированное просто сразу сохраняется. Видимо, будем делать опциональную панель "Изменения" с кнопкой "Применить", которую можно будет включать атрибутом.
UI:
Нет, "родные" компоненты живут на той же странице. Давать доступ кастомным компонентам ко всему фронту страшно - хочется, чтобы доступ у компонента был только к своим собственным данным.
Да, такие же мысли. Это хочется совместить с некоей "схемой" атрибутов, которая будет проверяться на стороне базы - чтобы ловить опечатки и тому подобные ошибки. Сейчас атрибуты не проверяются никак, кроме как глазами в UI "что всё работает".
Про аудиторию: кроме MVP хочется попробовать стать и платформой для
разработки бизнес-приложений. Предположение, что наша гибкость даёт возможность
реализовывать сложные проекты, а цена разработки и лицензии при этом ниже, чем у
гигантов навроде MS CRM. Проблему с техническим порогом вхождения стараемся
решать близостью FunQL к SQL, и использованием стандартного JS в остальных
местах. И ищем вендоров, которым интересно нас внедрять, чтобы внедряли не сами
компании.
Наконец, ещё думаем про себя как про возможную платформу для приложений: на базе
нас можно реализовывать свои сервисы, и писать к ним свой интерфейс.
Спасибо!
Согласен, про язык можно было рассказать чуть больше. Попробую это сделать здесь.
Если кратко: свой язык делался потому что чесалось для скорости и удобства разработки. Были сначала мысли как-то на уровне определения явно разделять данные и отображение. Например, запросы писать на чистом pgSQL, а атрибуты для отображения задавать отдельно формулами (тоже на pgSQL). В итоге оказалось, что писать запросы так неудобно - формат, когда прямо в запросе есть атрибуты, разработчику решений позволяет работать эффективнее.
Потом язык уже оброс своими фичами, которые специфичны для базы: например, оператор =>, который позволяет обходиться без JOIN, и операции с наследованием таблиц (которое у нас реализовано по-другому, чем в самом PostgreSQL). При этом мы стараемся держаться максимально близко к изначальному SQL - он зачастую хорошо известен целевой аудитории продукта, разработчикам (даже начинающим) бизнес-приложений. Хочется, чтобы они могли понять идею атрибутов за пару часов и уже эффективно работать.
При этом абсолютно верно, что данные и отображение мешать - это в целом плохой тон, и мы тут именно что рисуем GUI на SQL. Тут две мысли. Во-первых, на практике для большинства форм и таблиц это кажется приемлемым решением, потому что "логики" в запросе, как таковой, почти нет -- если убрать все атрибуты, то это простой SELECT с возможными WHERE по нескольким параметрам, и с ORDER BY, который скорее уже часть отображения. Такие запросы составляют большую часть разработки бизнес-приложений.
Во-вторых, мы хотим реализовать вызов user view (они же как функции) изнутри других user view, и написать гайдлайн, в котором будем советовать для любых нетривиальных запросов разделять так данные и отображение. Условно, один сложный запрос без атрибутов, и один или несколько, которые делают простой SELECT из него и только добавляют нужных опций (или дополнительно его фильтруют, скажем). Это всё в планах.
Про ЯП общего назначения: не хотелось давать возможность писать произвольный код внутри запроса. SQL тут хорош как раз тем, что он (в изначальном виде) только про данные. Все атрибуты у нас, как и сам результат запроса, декларативны - это либо значения, либо формулы. Поэтому в итоге выходит, что весь UI задан набором таких значений и формул. Это, с одной стороны, ограничивает разработчика (можно было бы дать возможность, скажем, писать UI на JS, и разрешить вообще что угодно). С другой -- для большинства отображений это повышает скорость разработки и читаемость кода. Например.
SELECT balance @{ cell_color = CASE WHEN balance < 0 THEN 'red' ELSE 'green' }- тут сразу понятно, что выбирается и какая логика раскраски ячеек. Ну и наконец, это позволяет нам гораздо свободнее внедрять различные оптимизации и улучшения в интерфейс, чем если бы возможен был произвольный код на любом уровне.Надеюсь, идея стала понятнее!
Про базу. На всякий случай: фронт и базу я тут буду различать, потому что базой можно пользоваться отдельно:
Да, схемы, таблицы и колонки произвольные везде, кроме схемы
publicи автоматического числовогоidво все таблицы (его тоже есть планы не требовать, но потом);Поправьте, если не про то. Логика модификации данных не генерится из
SELECTов, а сделана хитрее: в запрос внутри вставляются доп. колонки, и для каждой ячейки из запроса по API возвращается информация, из какой она реально записи. Фронт использует эту информацию, чтобы давать редактировать почти любые поля. Про вмешательство не понял, можно пример?У базы есть вызов
/transaction, куда можно передавать произвольный список изменений. На уровне фронта раньше было явно, сейчас нет - пользователям оказались непонятны явные гранзакции. Про дочернюю таблицу не понял, уточните?Про интерфейс:
Да, по сути графики из статьи - и есть произвольные контролы на форме. В
iframeконтрола прилетают данные из ячейки, и есть вызовы, чтобы данные менять;Расширять нельзя, не придумали пока, как - есть только разные атрибуты для настройки. Новый можно, как в (1);
FunQL и сама база на самом деле вообще не знают, что есть фронт или какая-то логика отображения. По сути это просто SQL-база с добавленными (произвольными) атрибутами, которые можно интерпретировать, как угодно. Фронт же на основании значений атрибутов строит всю страницу.
Перестраивается фронтом после каждого редактирования. Забавный пример: если редактируете "код" редактора кода, то он при сохранении сразу будет меняться.
Да, планируется позже. При этом, скорее всего, в нём нельзя будет собрать совсем произвольный запрос, но всегда можно редактировать код.
Хорошая мысль, потому что кажется, что такое можно сделать отдельно от (5), чуть ли не всплывающее окошко из редактора кода. Подумаем.
Всё верно. Визуальный редактор у нас в планах, но идея - дать максимальную гибкость за счёт простого, но кода.