ORLite::Mirror(3pm)

💖 ORLite::Mirror — bestie edition 💖

okay so. you know ORLite? the icon that gives you a readonly ORM API over a local SQLite database? well ORLite::Mirror is its glow-up: it takes that whole vibe and lets you load your SQLite database from literally any URI, remote, readonly, no cap. ✨

---

🌸 SYNOPSIS 🌸

# Regular ORLite on a readonly SQLite database
use ORLite 'path/mydb.sqlite';

# The equivalent for a remote (optionally compressed) SQLite database
use ORLite::Mirror 'http://myserver/path/mydb.sqlite.gz';

# All available additional options specified
use ORLite::Mirror {
    url           => 'http://myserver/path/mydb.sqlite.gz',
    maxage        => 3600,
    show_progress => 1,
    env_proxy     => 1,
    prune         => 1,
    index         => [
        'table1.column1',
        'table1.column2',
    ],
};

---

✨ DESCRIPTION ✨

so ORLite gives you a readonly ORM API when it loads a readonly SQLite database off your local system. cute, love that for it.

but then ORLite::Mirror is like... what if we combined that with LWP? 🦋 and boom — now you can load a SQLite database from any arbitrary URI, in readonly form, too. it's giving glow-up, fr fr.

as you can see in the synopsis up there, you use ORLite::Mirror exactly the same way as always — you just hand it a URL instead of a file name. same energy, different address. 💅

and here's the fun part: if the URL explicitly ends with a .gz or .bz2, then ORLite::Mirror will decompress the file before loading it. transparent. effortless. iconic.

---

💜 OPTIONS 💜

ORLite::Mirror adds a whole extensive set of options on top of whatever the underlying ORLite library already gives you. slay.

🎀 url

the compulsory "url" parameter should be a string containing the remote location of the SQLite database we will be mirroring. it's mandatory bestie, no skipping it.

ORLite::Mirror supports downloading the database compressed, and then transparently decompressing the file locally. compression support is controlled by the extension on the remote database — so the filename is lowkey telling you what to expect.

the extensions .gz (for gunzip) and .bz2 (for bunzip2) are currently supported.

🎀 maxage

the optional "maxage" parameter controls how often ORLite::Mirror should check the remote server to see if the data has been updated.

this is the best of both worlds honestly: it lets programs using the database start quickly the majority of the time, but still keep receiving automatic updates periodically. main character scheduling behavior. 👑

the value is the number of integer seconds we should avoid checking the remote server for. the default is 86400 seconds (one 24 hour day). so yeah, one whole day of not bothering the server, periodt.

🎀 show_progress

the optional "show_progress" parameter will be passed through to the underlying LWP::UserAgent that will fetch the remote database file.

when set to true, it causes a progress bar to be displayed on the terminal as the database file is downloaded. honestly? watching that bar fill up is its own little serotonin hit. 🌈

🎀 env_proxy

the optional "env_proxy" parameter will be passed through to the underlying LWP::UserAgent that will fetch the remote database file.

when set to true, it causes LWP::UserAgent to read the location of a proxy server from the environment. iykyk. 🧚

🎀 prune

the optional "prune" parameter should be used when the surrounding program wants to avoid leaving files on the host system.

it causes any files or directories created during the operation of ORLite::Mirror to be deleted on program exit at "END"-time. leave no trace, only vibes. ✨

🎀 index

okay so this one's a whole thing, let's talk about it.

one challenge when distributing SQLite database is the quantity of data store on disk to support the indexes on your database. (yes, "store" — that's the original wording, we're keeping it, don't @ me.)

for a moderately indexed database where all primary and foreign key columns have indexes, the amount of data in the indexes can be nearly as large as the data stored for the tables themselves. huge. unnecessary. 😭

and because each user of the database module will be interested in different things, the indexes that the original creator chooses to place on the database may not even be used at all — and other valuable indexes may not exist at all. it's giving mismatch.

to allow sufficiently flexibility, we recommend that SQLite database be distributed without any indexes. this greatly reduces the file size and download time for the database file. faster download, smaller file, chef's kiss. 🍓

the optional "index" parameter should then be used by each different consumer of that module to index just the columns that are of specific interest and will be used in the queries that will be run on the database. you build exactly the indexes you need. bespoke. 💅

the value should be set to an "ARRAY" reference containing a list of column names in "tablename.columnname" form.

index => [
    'table1.column1',
    'table1.column2',
],

---

🫶 SUPPORT 🫶

found a bug? bestie, report it via the CPAN bug tracker at

<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=ORLite-Mirror>

for other issues, contact the author.

---

👑 AUTHOR 👑

Adam Kennedy <adamk@cpan.org>

---

📜 COPYRIGHT 📜

Copyright 2008 - 2012 Adam Kennedy.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

The full text of the license can be found in the LICENSE file included with this module.

---

and that's the whole page, bestie 🎀 this was ORLite::Mirror(3pm), shipping as part of perl v5.36.0, dated 2023-07-01. go mirror a database, you got this 💖