Skip to content

Simplify API, instantiate SqliteClient instead of Factory #47

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
clue opened this issue Nov 10, 2021 · 0 comments
Open

Simplify API, instantiate SqliteClient instead of Factory #47

clue opened this issue Nov 10, 2021 · 0 comments
Labels
BC break help wanted Extra attention is needed new feature New feature or request
Milestone

Comments

@clue
Copy link
Owner

clue commented Nov 10, 2021

There are plans to simplify the API by removing the Factory and instead replacing it with a simpler SqliteClient constructor. In other words, this:

$factory = new Clue\React\SQLite\Factory();
$db = $factory->openLazy('users.db');

$db->exec('CREATE TABLE IF NOT EXISTS foo (id INTEGER PRIMARY KEY AUTOINCREMENT, bar TEXT)');

Could potentially look like this:

$db = new Clue\React\Sqlite\SqliteClient('users.db');

$db->exec('CREATE TABLE IF NOT EXISTS foo (id INTEGER PRIMARY KEY AUTOINCREMENT, bar TEXT)');

Internally, the SqliteClient would work similar to what is currently called a "lazy" client, but we'll probably get rid of this wording altogether. This means it would automatically create the underlying database process only when it's actually needed and will stop this process after a short while when it is not in use anymore. What is currently called "idle" time would probably be reworded to be more of a "keepalive" with much lower defaults.

Additionally, we'll probably fire "open" and "close" events as needed (loosely inspired by https://github.com/clue/reactphp-eventsource). Unlike the current version, my idea is to also keep the instance in a usable state even after calling close() on it. Reusing the same instance at a later time makes a lot more sense in long-running applications instead of locking it in an unusable state.

This is obviously a BC break, but there are no plans to break any of the existing code besides this. Most consumers should be able to upgrade to the new instantiation without issues, actual query APIs etc. would not be affected.

Obviously the biggest hindrance: I'm not entirely sure about the casing of the namespace and class name (SQLite vs. Sqlite).

Builds on top of #39, #45 and others

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BC break help wanted Extra attention is needed new feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant