# Samostojna uporaba

Queuety je zapakiran kot vtičnik za WordPress, vendar večina izvajalnega okolja
za delovanje ne potrebuje aktivne zahteve WordPress.

Čakalna vrsta, mehanizem potekov dela, stroji stanj, signali, artefakti, paketna obdelava,
razporejanje, beleženje, metrike in upravljanje virov delujejo z istimi
podatkovnimi tabelami MySQL. Če lahko drug proces PHP odpre isto podatkovno zbirko, lahko to jedro uporablja neposredno.

To je meja samostojne uporabe v Queuety. Mehanizem za orkestracijo, ki uporablja podatkovno zbirko, je mogoče uporabljati zunaj WordPress. Mostovi WordPress pa ostajajo del WordPress.

## Kaj deluje zunaj WordPress

Z neposredno povezavo `Connection` lahko samostojen proces inicializira Queuety in uporabi iste metode vmesnika kot vtičnik za osnovno izvajalno okolje:

- razpošiljanje opravil
- izvajanje delavcev in skupin delavcev
- sestavljanje in razpošiljanje potekov dela
- pošiljanje signalov, odobritev in vhodnih podatkov poteka dela
- sestavljanje in razpošiljanje strojev stanj
- pregled stanja poteka dela in stroja
- shranjevanje in branje artefaktov
- upravljanje paketne obdelave, veriženja in ponavljajočih se urnikov
- poizvedovanje po dnevnikih, metrikah, čakalnih vrstah in stanju izvajalnega okolja

To pomeni, da lahko zunanji izdelek dostopa do istega stanja orkestracije, ne da bi prej zagnal WordPress, če uporablja isto podatkovno zbirko in ista imena tabel.

Skupine delavcev so trenutno izjema: `Queuety::run_worker_pool()` in
`Queuety::run_auto_scaling_worker_pool()` berejo konstante WordPress `DB_HOST`,
`DB_NAME`, `DB_USER` in `DB_PASSWORD` namesto inicializirane povezave, zato mora samostojen proces te konstante določiti, preden zažene skupino ([#5](https://github.com/inline0/queuety/issues/5)).

## Kaj ostaja znotraj WordPress

Mostna plast, specifična za WordPress, je še vedno odvisna od naloženega WordPress.

To vključuje:

- inicializacijo vtičnika in vedenje ob aktivaciji v `queuety.php`
- `Queuety::on_action()`, ki zahteva `add_action()`
- `Queuety::replace_wp_cron()` in `Queuety::restore_wp_cron()`, ki sta odvisna od filtrov WordPress cron in `do_action()`
- dejansko pot registracije ukazov `wp queuety ...`, ki je odvisna od tega, ali WP-CLI naloži WordPress

Ti deli so prilagodniki okoli jedra izvajalnega okolja. Sami po sebi niso izvajalno okolje.

## Inicializacija

Samostojna pot je namenoma preprosta. Odprite povezavo `Connection` s podatkovno zbirko,
inicializirajte vmesnik in poskrbite, da shema obstaja.

```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();
```

Nato je na voljo običajni API izvajalnega okolja:

```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();
```

## Poimenovanje tabel

Pri samostojni uporabi niso potrebna prav imena tabel WordPress. Potrebna je le stabilna strategija predpon.

Če Queuety povežete s podatkovno zbirko WordPress, uporabite isto predpono kot vtičnik. Če Queuety uporabljate v ločeni podatkovni zbirki, je lahko predpona povezave poljubna, kot jo pričakuje gostiteljska aplikacija. Del imen tabel, specifičen za Queuety, še vedno določata `QUEUETY_TABLE_PREFIX` in preglasitve posameznih tabel.

Vgrajena izvajalna okolja, ki si delijo podatkovno zbirko, lahko ta del, specifičen za Queuety, nastavijo za vsako povezavo posebej:

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

S tem ostane predpona podatkovne zbirke WordPress nespremenjena, tabele, kot je `queuety_jobs`, pa se razrešijo v `wp_themequeue_jobs`.

## Miselni model

Delitev si najlažje predstavljamo takole:

- jedro Queuety = čakalna vrsta, delavci, poteki dela, stroji stanj, signali, artefakti in metapodatki izvajalnega okolja
- prilagodnik WordPress = inicializacija vtičnika, mostovi za kavlje, zamenjava WP-Cron in registracija WP-CLI

Tako ohranite en mehanizem za orkestracijo, integracija dogodkov in zahtev, specifična za WordPress, pa ostane tam, kjer sodi.