# Самостоятелна употреба

Queuety е пакетиран като плъгин за WordPress, но по-голямата част от средата за изпълнение всъщност не се нуждае от активна заявка към WordPress.

Опашката, системата за работни процеси, машините на състоянията, сигналите, артефактите, пакетната обработка, планирането, регистрирането, метриките и управлението на ресурсите работят с едни и същи таблици на MySQL. Ако друг процес на PHP може да отвори същата база данни, той може да използва директно тази основна функционалност.

Това е границата на самостоятелната работа в Queuety. Двигателят за оркестрация, базиран на база данни, може да се използва извън WordPress. Мостовете WordPress все още са част от WordPress.

## Какво работи извън WordPress

При директна връзка с `Connection` самостоятелен процес може да инициализира Queuety и да използва същите методи на фасадата като плъгина за основната среда за изпълнение:

- изпращане на задачи
- стартиране на работници и пулове от работници
- създаване и изпращане на работни процеси
- изпращане на сигнали, одобрения и входни данни за работни процеси
- създаване и изпращане на машини на състоянията
- проверка на състоянието на работните процеси и машините
- съхраняване и прочитане на артефакти
- управление на пакетната обработка, свързването във вериги и повтарящите се графици
- отправяне на заявки за регистрационни файлове, метрики, опашки и състоянието на средата за изпълнение

Това означава, че външен продукт може да работи със същото състояние на оркестрацията, без първо да зарежда WordPress, стига да използва същата база данни и същите имена на таблиците.

Пуловете от работници засега са единственото изключение: `Queuety::run_worker_pool()` и `Queuety::run_auto_scaling_worker_pool()` четат константите WordPress `DB_HOST`, `DB_NAME`, `DB_USER` и `DB_PASSWORD` вместо инициализираната връзка, затова самостоятелен процес трябва да дефинира тези константи, преди да стартира пул ([#5](https://github.com/inline0/queuety/issues/5)).

## Какво остава в WordPress

Слоят от мостове, специфичен за WordPress, все още зависи от зареждането на WordPress.

Това включва:

- началното зареждане и поведението при активиране на плъгина в `queuety.php`
- `Queuety::on_action()`, за което е необходим `add_action()`
- `Queuety::replace_wp_cron()` и `Queuety::restore_wp_cron()`, които зависят от филтрите WordPress cron и `do_action()`
- реалният път за регистриране на командите `wp queuety ...`, който зависи от зареждането на WP-CLI WordPress

Тези компоненти са адаптери около основната среда за изпълнение. Те не са самата среда за изпълнение.

## Инициализация

Самостоятелният път е умишлено опростен. Отворете `Connection`, свързана с база данни, инициализирайте фасадата и се уверете, че схемата съществува.

```php
use Queuety\Connection;
use Queuety\Queuety;

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
);

Queuety::init( $conn );
Queuety::ensure_schema();
```

След това е налична обичайната среда за изпълнение API:

```php
Queuety::dispatch( 'send_email', [ 'to' => 'user@example.com' ] );

$workflow_id = Queuety::workflow( 'report' )
    ->then( FetchReportData::class )
    ->then( RenderReport::class )
    ->dispatch( [ 'report_id' => 42 ] );

$machine_id = Queuety::machine( 'agent_session' )
    ->state( 'awaiting_input' )
    ->on( 'message', 'planning' )
    ->state( 'planning' )
    ->action( PlanSessionAction::class )
    ->dispatch();
```

## Именуване на таблиците

Самостоятелната употреба не изисква конкретно имена на таблици за WordPress. Необходима е само стабилна стратегия за префикси.

Ако свържете Queuety с база данни на WordPress, използвайте същия префикс като плъгина. Ако използвате Queuety в отделна база данни, префиксът на връзката може да е какъвто очаква хост приложението ви. Частта от имената на таблиците, специфична за Queuety, все още се контролира от `QUEUETY_TABLE_PREFIX` и настройките за отделните таблици.

Вградени среди за изпълнение, които споделят една база данни, могат да зададат тази част, специфична за Queuety, за всяка връзка:

```php
$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
    table_prefix: 'themequeue_',
);
```

Така префиксът на базата данни на WordPress остава непроменен, а таблици като `queuety_jobs` се преобразуват в `wp_themequeue_jobs`.

## Модел на работа

Най-ясно е разделението да се разбира така:

- ядро на Queuety = опашка, работници, работни процеси, машини на състоянията, сигнали, артефакти и метаданни на средата за изпълнение
- адаптер на WordPress = начално зареждане на плъгина, мостове за куки, замяна на WP-Cron и регистриране на WP-CLI

Така се запазва един двигател за оркестрация, а интеграцията със събитията и заявките, специфична за WordPress, остава там, където ѝ е мястото.