NoSQL жив

Цитата (Телебашня @ 05.10.2026 - 10:39)

про то, что нужно делать бэкапы ты, видимо, не в курсе?

Нахуя мне бекапы Санты Барбары?
Размещено через приложение ЯПлакалъ

Цитата (VampirBFW @ 5 окт 2026 в 09:10)

Цитата (DJKashei @ 5 окт 2026 в 09:09) Хм... что-то не понимаю, что будет храниться в БД? Связки логин-пароль? Так овердохрена решений начиная от гуевых с облачной синхронизацией и заканчивая cli-шным pass. Файлы там будут хранится файлы, в обьектах, в БД. Представляешь вся моя коллекция санты барбары и теории большого взрыва будет не отдельными файлами на харде а блядь в базе данных. Это же заебись.

Какие-то сомнительные преимущества:
- Как этот файл с видео отправить, например, на стриминговый сервис типа Plex? Каждый раз извлекать, сохранять в файловой системе и затем отправлять?
- Как его отредактировать, если нужно средствами какой-то утилиты?
- Что произойдет если эта база данных сдохнет? Битый сектор, сбой электричества?
Раньше сбой приводил к проблеме в конкретном файле, а тут грозит потерей всех данных? Или предполагается, что эту базу нужно регулярно бэкапить, т.е. докупать диски и пилить планы обслуживания и развертывания. А что если база на 10 Терабайт? Сколько она будет восстанавливаться?

Цитата (evilsun @ 5 окт 2026 в 11:04)

Как этот файл с видео отправить, например, на стриминговый сервис типа Plex? Каждый раз извлекать, сохранять в файловой системе и затем отправлять? - Как его отредактировать, если нужно средствами какой-то утилиты?

Элементарно! Нужно просто написать драйвер, который позволит монтировать базу как файловую систему!

Цитата (ackcmd @ 05.10.2026 - 11:19)

Элементарно! Нужно просто написать драйвер, который позволит монтировать базу как файловую систему!

Нихуя себе идея, а зачем?
Размещено через приложение ЯПлакалъ

Цитата (DanLo @ 5 окт 2026 в 08:45)

Если вы пользователь Linux и вам надоело хранить данные в плоских файлах, то я хочу сообщить, что в скором времени закончу работу над утилитой, которая сильно облегчит этот процесс. Linux x64.

СРАЗУ ВНИМАНИЕ!
Все что описано ниже - кодревью построенное нейросеткой. Его можно принимать, можно не принимать. Но обратить внимание надо - во многих местах помогает, т.к. нейронка ориентируется на общие пракитики. Кто не понимает - можете не читать - все равно не поймете - просто оцените количество того, что нейронка доколебалась до страницы текста.

И да - сейчас такое ревью мы используем в работе - от этого не уйти - хорошо оно или плохо
=================


Да, придраться можно, хотя сам фрагмент выглядит достаточно аккуратно. Прямо явного «ужаса» на скрине я не вижу. Я бы на ревью отметил примерно следующее.

Самое существенное — **контракт `argc/argv`**:

```c
if (argc == 0) {
routing.command = cmd_version;
return routing;
}

const char * const command = argv[0];
```

Если это обычные `argc/argv` из `main()`, то `argc == 0` практически не является нормальным случаем, потому что `argv[0]` — имя программы. Значит, где-то выше явно делается что-то вроде:

```c
router(argc - 1, argv + 1, app);
```

Если так — всё нормально, но я бы хотел увидеть это **явно зафиксированным контрактом**, иначе функция выглядит подозрительно.

Второе — потенциальный UB:

```c
strcmp(command, route)
```

Если `argv[0] == NULL` или `routes[i].route == NULL`, будет беда. Если таблица `routes` гарантированно валидна — окей, но опять же это инвариант, который хорошо бы либо закрепить, либо хотя бы неявно не нарушать.

Третье — вот это:

```c
for (int i = 0; i < routes_size; i++)
```

Если `routes_size` имеет тип `size_t`, я бы написал:

```c
for (size_t i = 0; i < routes_size; ++i)
```

Иначе появляется signed/unsigned comparison и теоретически неправильный диапазон типов. Для маленькой таблицы маршрутов практически неважно, но на code review это нормальное замечание.

Четвёртое — я бы не лазил несколько раз в:

```c
routes[i]
```

а написал примерно:

```c
const Route *const route = &routes[i];

if (strcmp(command, route->route) == 0) {
if (!route->validator(argc, argv, &routing, app)) {
return routing;
}

routing.command = route->executor;
return routing;
}
```

Тут не производительность важна, а читаемость: **мы рассматриваем один route entry как сущность**.

Пятое — это `.c`, а код использует:

```c
nullptr
constexpr
```

То есть фактически проект требует **C23**. Если это сознательное решение — отлично. Если автор рассчитывает на обычный C11/C17 или широкий набор компиляторов, это уже проблема переносимости. Я бы обязательно посмотрел `CMakeLists.txt` и убедился, что там явно стоит C23, а не получилось «у меня GCC это съел». На скрине `CMakeLists.txt` как раз есть.

Ещё маленький stylistic nit:

```c
Routing router(const int argc, ..., const App app)
```

`const` у аргументов, передаваемых по значению:

```c
const int argc
const App app
```

в публичном интерфейсе почти ничего не даёт. Для тела функции оно запрещает автору случайно изменить локальную копию, но API от этого не становится более const-correct. Я бы скорее написал:

```c
Routing router(int argc, const char *const argv[], App app)
```

если нет специального style guide.

И я бы посмотрел на:

```c
const Validator validator = routes[i].validator;

if (!validator(...))
```

Если `validator` когда-либо допускается `NULL`, здесь падение. Возможно, по архитектуре каждый route обязан иметь validator — тогда замечание снимается.

А вот к этому:

```c
Routing routing = {
.command = nullptr,
.message = nullptr,
.code = 0,
};
```

я особо не придираюсь. Нормальная явная инициализация. Разве что если `code` — статус, enum вроде `ROUTING_OK` был бы выразительнее магического `0`.

Ещё можно поспорить о названии:

```c
Routing router(...)
```

`router` звучит как объект, а функция фактически **разрешает маршрут**. Мне больше нравилось бы:

```c
route(...)
resolve_route(...)
make_routing(...)
```

но это уже вкусовщина.

И ещё: линейный поиск

```c
for (...) {
strcmp(...)
}
```

для 10–50 CLI-команд **абсолютно нормален**. Я бы не принимал на ревью попытку «оптимизировать» его hashmap'ом — это как раз было бы усложнение ради ничего.

**Итого:** из картинки я вижу один вопрос, который реально хочу проверить — **семантика `argc/argv`**, плюс C23/переносимость и `size_t`. Остальное — скорее уровень polishing. Код в целом выглядит довольно чистым, а не таким, который хочется завернуть на ревью целиком.
Это сообщение отредактировал HellMagic - 5 окт 2026 в 11:49

Я храню файлы на диске R в основном, это у меня рейд так называется. Пока в линуксе не сделают диск R, он мне не подходит. А эти свои var= mount= херомоунт в зад торвальдсу засуньте.

Цитата (VampirBFW @ 5 окт 2026 в 09:10)

Цитата (DJKashei @ 5 окт 2026 в 09:09) Хм... что-то не понимаю, что будет храниться в БД? Связки логин-пароль? Так овердохрена решений начиная от гуевых с облачной синхронизацией и заканчивая cli-шным pass. Файлы там будут хранится файлы, в обьектах, в БД. Представляешь вся моя коллекция санты барбары и теории большого взрыва будет не отдельными файлами на харде а блядь в базе данных. Это же заебись.

Т.е. под капотом окажется клон sqllite )
Ну и что на счет секретов? Просто так хранить пароли и ключи? А как передавать в сборку? Гит уже неплохо справляется с хранением ключей. В чем прелесть проекта - я так и не увидел. Очередное локальное хранилище для пары-тройки сотен строк? Подчеркну - не пары-тройки миллиардов строк, а сотен всего лишь!