
# Önálló használat

A Queuety WordPress bővítményként van csomagolva, de a futtatókörnyezet nagy részéhez nincs szükség aktív WordPress kérésre.

A várólista, a munkafolyamat-motor, az állapotgépek, a jelzések, az artefaktumok, a kötegelés, az ütemezés, a naplózás, a metrikák és az erőforrás-kezelés mind ugyanazon MySQL táblákon futnak. Ha egy másik PHP folyamat hozzáfér az adatbázishoz, közvetlenül használhatja ezt a magot.

Ez jelenti az önálló használat határát a Queuety esetében. Az adatbázis-alapú vezénylőmotor WordPress környezetén kívül is használható. A WordPress hidak továbbra is a WordPress környezetéhez tartoznak.

## Mi működik WordPress környezetén kívül

Közvetlen `Connection` használatával egy önálló folyamat inicializálhatja a Queuety értéket, és ugyanazokat a felületi metódusokat használhatja a központi futtatókörnyezethez, mint a bővítmény:

- feladatok indítása
- workerek és workerpoolok futtatása
- munkafolyamatok összeállítása és indítása
- jelzések, jóváhagyások és munkafolyamat-bemenet küldése
- állapotgépek összeállítása és indítása
- munkafolyamat- és gépállapot vizsgálata
- artefaktumok tárolása és beolvasása
- kötegelés, láncolás és ismétlődő ütemezések működtetése
- naplók, metrikák, várólisták és futásidejű állapot lekérdezése

Ez azt jelenti, hogy egy külső termék hozzáférhet ugyanahhoz a vezénylési állapothoz anélkül, hogy előbb elindítaná a WordPress értéket, feltéve, hogy ugyanazt az adatbázist és táblaneveket használja.

A workerpoolok jelenleg kivételt képeznek: a `Queuety::run_worker_pool()` és a `Queuety::run_auto_scaling_worker_pool()` az inicializált kapcsolat helyett a WordPress `DB_HOST`, `DB_NAME`, `DB_USER` és `DB_PASSWORD` konstansokat olvassa, ezért egy önálló folyamatnak a pool indítása előtt definiálnia kell ezeket a konstansokat ([#5](https://github.com/inline0/queuety/issues/5)).

## Mi marad WordPress környezetén belül

A WordPress-specifikus hídréteg továbbra is attól függ, hogy a WordPress betöltődött-e.

Ide tartozik:

- a bővítmény inicializálása és aktiválási működése a `queuety.php` környezetében
- a `Queuety::on_action()`, amelyhez szükség van a `add_action()` értékre
- a `Queuety::replace_wp_cron()` és a `Queuety::restore_wp_cron()`, amelyek a WordPress cron szűrőitől és a `do_action()` értéktől függenek
- a tényleges `wp queuety ...` parancsregisztrációs útvonal, amely attól függ, hogy a WP-CLI betölti-e a WordPress értéket

Ezek a részek a központi futtatókörnyezet köré épülő adapterek. Nem maga a futtatókörnyezet.

## Inicializálás

Az önálló útvonal szándékosan egyszerű. Nyisson meg egy adatbázis-alapú `Connection` példányt, inicializálja a felületi réteget, és gondoskodjon róla, hogy a séma rendelkezésre álljon.

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

Ezután elérhetővé válik a szokásos futásidejű 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();
```

## Táblanévadás

Az önálló használathoz nem szükséges kifejezetten WordPress-táblaneveket használni. Csak stabil előtagolási stratégiára van szükség.

Ha a Queuety példányt WordPress adatbázisra állítja, használja ugyanazt az előtagot, mint a bővítmény. Ha a Queuety értéket külön adatbázisban használja, a kapcsolat előtagja a gazdaalkalmazás elvárásai szerint tetszőleges lehet. A Queuety-specifikus táblarészt továbbra is a `QUEUETY_TABLE_PREFIX` és a táblánkénti felülbírálások határozzák meg.

Az egy adatbázist megosztó beágyazott futtatókörnyezetek kapcsolatonként állíthatják be ezt a Queuety-specifikus részt:

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

Így az WordPress adatbázis-előtagja érintetlen marad, és az olyan táblák, mint a
`queuety_jobs`, a következőre oldódnak fel: `wp_themequeue_jobs`.

## Mentális modell

A felosztást így érdemes elképzelni:

- Queuety core = sor, workerek, munkafolyamatok, állapotgépek, jelek, artefaktumok és futásidejű metaadatok
- WordPress adapter = bővítményindítás, hookhidak, WP-Cron-csere és WP-CLI-regisztráció

Így megmarad egyetlen vezérlőmotor, miközben az WordPress-specifikus esemény- és
kérésintegráció a megfelelő helyen marad.
