Client-server interaction development beggining by Reeliks · Pull Request #37 · Reeliks/blaze

Reeliks · 2024-05-20T21:40:48Z

Начинается полномасштабная работа над взаимодействием клиента и сервера базы данных!

Инфо-каналы для возможности гибко менять выходную точку сообщений, работающие на mpsc
Клиентское подключение, имеющее ключ для взаимодействия с бд и прототип настраиваемого жизненного цикла
Рефакторинг структуры серверного конфига, добавление новых полей
Вынесение хэндлинга консольных команд в соответствующую структуру
Замена blaze create на blaze init, генерирующий только %.manage.blz файл со всеми доступными конфигурационными полями (manage.blz перевоплотился в main.manage.blz, имя можно менять)
Улучшение запуска сервера путём добавления понятных сообщений об ошибках и служебной информации о самом запуске, возможность выбирать manage file при запуске без написания .manage.blz
Другие небольшие правки в коде после рефакторинга
Мыслю над синтаксисом языка, взглянуть можно в README.md

…create' and made 'blaze init' instead

BlackSoulHub · 2024-05-21T04:33:32Z


-      - name: Check formatting
-        run: cargo fmt -- --check
+#      - name: Check formatting


По какой-то причине не проходит проверку, даже когда всё нормально. Может, я чего-то не догоняю

Try to merge #38 to this branch

Ok let's try

Fix fmt

BlackSoulHub · 2024-05-21T12:23:29Z

+http-body-util = "0.1"
+hyper = { version = "1", features = ["full"] }
+tokio = { version = "1", features = ["full"] }
+serde = { version = "1", features = ["derive"] }


Do not use versions like this. Specify full version.

Theoretically it can break build on users with older lib version

BlackSoulHub · 2024-05-21T12:28:17Z

-    shell::handling::handle_command_arguments()?;
-    Ok(())
+#[tokio::main]
+async fn main() {


I think we need move main to separate crate

As far as I know, using a combined lib and executable crate has dependency issues

I haven't heard about this approach and the problems without it. What advantages does it have?

I haven't heard about this approach and the problems without it. What advantages does it have?

Users of this crate (as lib) also download dependencies for shell app

You want to say that somebody who'd like to download the part of this project has to download other pieces?

You want to say that somebody who'd like to download the part of this project has to download other pieces?

In current realization it's true

Okay, it does make sense

BlackSoulHub · 2024-05-21T12:32:41Z

+
+pub const OFFICIAL_REPOSITORY: &str = "https://github.com/Reeliks/blaze";
+
+pub struct ShellCommandHandler {


I think best way for shell app - move to separate crate (i write about before)

BlackSoulHub · 2024-05-22T08:28:31Z

Как мы будем исполнять команды?

Только как функции наподобии этой?

function get_total_cart_price(products: Products): float {
    mut total: float = 0;
    product of products {
        total += product.price;
    };
    total
}

И как будет организована сама база данных?

Появилась подобная идея:

pub trait DatatabaseDriver {
    fn get_table(&mut self, table_name: &str) -> Result<Option<Table>>, DbError>;
}

и таблица:

struct Table {
    // fields ...
} 

impl Table {
    // TODO: write pretty API 
}

Reeliks · 2024-05-22T11:13:33Z

Данные будут храниться в одном файле с кастомным форматом (ломаю голову, как сделать его производительным для чтения и записи), сервер подключается к нему по указанию manage.blz. Этот файл должен иметь примерно такую же структуру, как json, но с указанием типов и длины значений и ключей для оптимизации.
Так как структура Datablaze очень гибкая (по крайней мере задумывается быть таковой) за счёт её подстраивания под данные при каждом запуске, лейны (от англ. переулок, что-то типа схемы, но в ней могут храниться одиночные ключ-значение пары, таблицы и другие такие же лейны) и таблицы в файле с данными сохраняются в виде ассоциативных массивов, что позволяет "превратить их карету в тыкву", а именно снять с них их звания и перевоплотить в хеш-таблицы при помощи преобразования типов в рантайме в нужных местах или по воле архитектора базы данных в изначальной структуре. Если запустить базу данных без всякой структуры, задекларированной ранее в blaze файлах, доступ к данным будет закрыт, так как для Blaze всех этих полей и записей без неё не существует.
Добавление абсолютно новых полей, таблиц и лейнов, а также удаление уже существующих проходит без проблем, но есть нюанс с их изменением, вытекающих из того, что структура очень подвижна: названия, типы данных и записанные значения необходимо изменять явно, например так: cash: int -> money: float. Могут быть и моменты, когда автоматического преобразования типов будет недостаточно, и здесь может понадобится ручное написание приведения типов путём пропуска через функции.

Код будет исполняться согласно структуре базы данных, а также правах пользователя, отправившего его. Это необязательно должны быть функции, но ими и созданными на стороне клиента также можно пользоваться (планами, то есть структурами данных в том числе). После исполнения кода на стороне базы данных все созданные объекты будут стёрты, т.к. существуют только на момент запроса (на самом деле здесь возможен и другой подход, который ещё стоит обдумать). Функции, созданные в manage.blz или в подключенных к нему пакетах, предоставляемые пользователю, не имеющему доступ к определённым участкам базы данных, могут взаимодействовать с этими самыми участками, что создаёт дополнительный уровень изоляции и может быть очень полезным в работе больших групп людей.

BlackSoulHub · 2024-05-22T12:09:12Z

Добавление абсолютно новых полей, таблиц и лейнов, а также удаление уже существующих проходит без проблем, но есть нюанс с их изменением, вытекающих из того, что структура очень подвижна: названия, типы данных и записанные значения необходимо изменять явно, например так: cash: int -> money: float. Могут быть и моменты, когда автоматического преобразования типов будет недостаточно, и здесь может понадобится ручное написание приведения типов путём пропуска через функции.

Я думаю, что мы должны хранить схему базы данных в где-то в файле и не позволять запускать приложение с невалидной схемой. В конце концов каст данных формата: int -> float, даже одинаковой битности - некорректная операция.
Для изменения схемы пользователь должен написать какую-нибудь миграцию

Код будет исполняться согласно структуре базы данных

Интересный момент по поводу кода. То как он выглядит очень похоже на какой-нибудь язык программирования.
Теоретически мы можем написать сервер как интерпретатор этого языка. Но подобная свобода довольно опасна. Теже функции в теории могут вызывать переполнение стека
Нам нужна законченная модель языка

Reeliks · 2024-05-22T18:02:28Z

Да, без хранения некоторой информации о последнем состоянии структуры файла данных не обойтись, так как помимо самих данных и их связей необходимо отдельно записывать id-инкременты (если это не uuid), "внешние ключи", ограничения (например, on cascade и restrict) и флаг дефолтного значения. Однако хранение типа отдельным параметром вызывает сомнения, поскольку в планах ввести тип wild, способный хранить любые значения, а также параметр базы данных, при котором миграция является не ещё одним этапом запуска, а процедурой, происходящей при попытке взаимодействия с данными.

Теоретически мы можем написать сервер как интерпретатор этого языка.

Ты попал в точку с интерпретатором. Да, будет использоваться новый интерпретируемый язык программирования, схожий по синтаксису на python и java script и имеющий больше возможностей, чем другие языки запросов. Разумеется, он не будет таким свободным, как языки программирования общего назначения, поэтому по поводу этого можно не волноваться.

Теже функции в теории могут вызывать переполнение стека

Здесь будет применено одно из свойств ACID — изменения будут применены к реальным данным только после успешного завершения кода. Вне самой базы данных (а возможно и в ней тоже) будут доступны коммиты.

Я нахожусь в активных размышлениях по поводу функционала языка и базы данных в целом, мне нужно некоторое время на это. Думаю, нам стоит завести документацию и уже туда складывать устоявшиеся концепты.

Reeliks · 2024-05-22T18:54:48Z

Я думаю, такой вариант может стать неплохим решением для миграций:

table machines -> manufacturing.assets.machines {
	name: str?,
	warehouse_number: int = 0
		-> warehouse_id: str!,
	current_factory: str?
		-get_factory_by_name> current_factories: set[db.manufacturing.factories],
	responsible: db.workers,
	release_year: int[>1925 <2150],
	next_inspection: datetime[utc]?,
	broken: bool = false,
	notes: str
		-notes_to_extra> extra_info: dict[str],
};

function get_factory_by_name(factory_name: str): db.manufacturing.factories {
	return db.manufacturing.factories.(name=factory_name)[..1]; // [..1] must be considered
} // Then the transformation from a link into a set of links happens automatically

function notes_to_extra(notes: str): dict[str] {
	mut extra: dict[str] = {};
	note of notes.split(r"\n[2]( )*\*") {
		extra.push(note.split(":", max_times=1));
	};
	return extra;
}

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

BlackSoulHub · 2024-05-23T04:23:14Z

при попытке обратиться к полю по прошлому имени произойдёт редирект на новую реализацию

А если в процессе миграций название этого поля было занято?

table machines -> manufacturing.assets.machines

Это переименование таблицы? Если да, то новое название это аналог пространства имён?

Reeliks · 2024-05-23T07:16:55Z

При поднятии сервера будет проводиться семантический анализ, который будет выявлять дубликацию имён в коде и самом файле с данными

Да, лейны вполне можно назвать пространствами имён, которые могут использоваться для разделения секций базы данных и управления доступом пользователей

BlackSoulHub · 2024-05-24T12:52:41Z

При поднятии сервера будет проводиться семантический анализ, который будет выявлять дубликацию имён в коде и самом файле с данными

Для меня это выглядит слишком нестрогим. Думаю нужно написать законченную версию языка с объяснение синтаксиса и посмотреть на каком-нибудь примере

Да, лейны вполне можно назвать пространствами имён, которые могут использоваться для разделения секций базы данных и управления доступом пользователей

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

Reeliks added 3 commits May 17, 2024 00:15

Improved server raising process, deleted db/create_db.rs with 'blaze …

fddff14

…create' and made 'blaze init' instead

Conflicts resolving after merging fs

0fb6f69

Info Channel, ServerInstance, Connections handling, CommandHandler

86d86de

Reeliks requested a review from VDFOREVER May 20, 2024 21:40

Reeliks and others added 2 commits May 21, 2024 00:46

Removing formatting test

b1b5d6c

README.md small update

3d86e39

BlackSoulHub reviewed May 21, 2024

View reviewed changes

BlackSoulHub and others added 5 commits May 21, 2024 08:34

fmt

0014765

uncomment fmt check

08135c7

Merge pull request #38 from BlackSoulHub/main

a66ab8e

Fix fmt

ClientConnection -> ClientSession, small rework

9adaabb

conflict resolving

47a39c6

BlackSoulHub reviewed May 21, 2024

View reviewed changes

Reeliks added the enhancement New feature or request label May 21, 2024


		pub const OFFICIAL_REPOSITORY: &str = "https://github.com/Reeliks/blaze";

		pub struct ShellCommandHandler {

Conversation

Reeliks commented May 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BlackSoulHub May 21, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BlackSoulHub commented May 22, 2024

Uh oh!

Reeliks commented May 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BlackSoulHub commented May 22, 2024

Uh oh!

Reeliks commented May 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reeliks commented May 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BlackSoulHub commented May 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reeliks commented May 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BlackSoulHub commented May 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Reeliks commented May 20, 2024 •

edited

Loading

BlackSoulHub May 21, 2024 •

edited

Loading

Reeliks commented May 22, 2024 •

edited

Loading

Reeliks commented May 22, 2024 •

edited

Loading

Reeliks commented May 22, 2024 •

edited

Loading

BlackSoulHub commented May 23, 2024 •

edited

Loading

Reeliks commented May 23, 2024 •

edited

Loading

BlackSoulHub commented May 24, 2024 •

edited

Loading