StorX
mvsqlite
StorX | mvsqlite | |
---|---|---|
5 | 26 | |
14 | 1,324 | |
- | - | |
10.0 | 0.0 | |
about 2 years ago | 8 days ago | |
PHP | Rust | |
GNU Affero General Public License v3.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
StorX
-
PHP in 2024
Apparently it is still common practice to have such "if bla is set, when do blub" everywhere in ones code? No functions with decorators or a similar or alternative concept? I would think there should be some kind of easy to use mechanism in place, that tends to avoid forgetting these ifs.
There are ... 60 lines of global logic, that is not encapsulated in any function or so?
Some of the functions are quite long. But I think mostly because they render out HTML.
At line 107 with the procedure printHeader starting, what I call PHP nightmare starts:
Switching back and forth between PHP, HTML and HTML with integrated JS (!!!) and CSS. All of course without syntax highlighting, but that is a minor issue. The major issue is treating HTML and JS and CSS as mere strings, instead of structured data, and the very bad readability of having procedures suddenly "end" and spit out some wild HTML, then suddenly continuing again, because some server side logic/decision is required at some place in that stream of unstructured data, whether some part is to be included or not, then the stream continues and then at some point one needs to actually check, that one did not forget to truly end the procedure. This has some of the worst readability. Maybe C code with bit magic is worse.
One can find this kind of approach in many, if not most, Wordpress plugins. What's more is, that this is also terrible for writing tests. The procedures do not return a value to check against. All is a side effect. Perhaps there is some PHP library that manipulates the PHP system, so that one can at least do string comparisons on the side effects. Like mocking, basically. But still terrible for testing.
For a comparison of how it should be done instead, check any templating engine, that at least separates template files from PHP code. Better, checkout SXML libraries, that treat HTML as structured data, a tree that can be traversed and pattern matched against, without pulling out arcane string manipulations or regular expressions. And then consider how one could write tests based on such structured data.
If this "HTML is a string, even on the server side before sending it" kind of approach is how a language treats HTML, then the language is not suitable to be directly used for HTML templating, without any additional library. This alone has caused uncountable security issues in so many projects.
I realize, that this is probably kind of a "one off script" and may not reflect other kinds of PHP code.
I did all of those things myself, years ago. And when I already had moved away from such an approach, I had to maintain a project, that was written this way. It had no tests of course. No fun. It has not that much to do with you personally being a good dev or not. I think it has to do with the ecosystem encouraging you to do these things. Outputting HTML like that should be declared illegal and should be impossible.
https://github.com/aaviator42/StorX/blob/main/StorX.php in comparison looks much better. It seems it does not output things directly. Everything seems wrapped nicely into methods. One obvious footgun seems to be another global state thing, that I really hope is not a thing in PHP itself:
const THROW_EXCEPTIONS = TRUE;
-
Why you should probably be using SQLite
I'm a huge fan of SQLite! My org's apps use it heavily, often via this simple key-value interface built on sqlite: https://github.com/aaviator42/StorX
Handles tens of thousands of requests a day very smoothly! :)
-
Show HN: My Single-File Python Script I Used to Replace Splunk in My Startup
My org's apps heavily use this simple key-value interface built on sqlite: https://github.com/aaviator42/StorX
There's also a bunch of other purpose-built tiny utilities on that GitHub account.
-
SQLite-based databases on the Postgres protocol? Yes we can
I wrote a small PHP library that gives you a key-value storage interface to SQlite files: https://github.com/aaviator42/StorX
I've been dogfooding for a while by using it in my side projects.
And there's a basic API too, to use it over a network: https://github.com/aaviator42/StorX-API
-
Soul – A SQLite RESTful Server
This is probably ready to be used in production by others, but I wrote a library that gives you a key-value storage interface to SQlite files: https://github.com/aaviator42/StorX
And there's an API too, to use it over a network: https://github.com/aaviator42/StorX-API
mvsqlite
-
FoundationDB: A Distributed Key-Value Store
I’ve been using FDB for toy projects for a while. It’s truly rock solid. That being said, I wish there were more layers.
Ideally someone could implement the firestore or dynamodb api on top.
https://github.com/losfair/mvsqlite
-
Go bindings to SQLite using Wazero
For the rough plan, it's Cloud Backed SQLite meets FoundationDB.
-
SQLite-based databases on the Postgres protocol? Yes we can
- Oh, and if you're wondering about backup to S3, they have that too: https://github.com/libsql/bottomless
- Uh, sqld can integrated with this https://github.com/losfair/mvsqlite, so now your SQLite is backed by FoundationDB!?
- Meanwhile Litestream exists https://github.com/benbjohnson/litestream/
- We Built Fly Postgres
-
Litestream doesn't do SQLite replication anymore (LiteFS does)
Shameless plug of my [mvSQLite](https://github.com/losfair/mvsqlite) project here! It's basically another distributed SQLite, but with support for everything expected from a proper distributed database: synchronous replication, strictly serializable transactions, + scalable reads and writes w/ multiple concurrent writers.
-
SQLite: QEMU All over Again?
This project looks really exciting!
I'm working on mvsqlite [1], a distributed SQLite based on FoundationDB. When doing the VFS integration I have always wanted to patch SQLite itself, but didn't because of uncertainty around correctness of the patched version...
A few features on my wishlist:
1. Asynchronous I/O. mvsqlite is currently doing its own prefetch prediction that is not very accurate. I assume higher layers in SQLite have more information that can help with better prediction.
2. Custom page allocator. SQLite internally uses a linked list to manage database pages - this causes contention on any two transactions that both allocate or free pages.
3. Random ROWID, without the `max(int64)` row trick. Sequentially increasing ROWIDs is a primary source of contention, and causes significant INSERT slowdown in my benchmark [2].
[1] https://github.com/losfair/mvsqlite
[2] https://univalence.me/posts/mvsqlite-bench-20220930
- Show HN: mvSQLite v0.2
- mvsqlite: Distributed SQLite built on FoundationDB
-
Show HN: Query SQLite files stored in S3
That DynamoDB VFS looks cool! I agree that the VFS api makes one think about plenty of crazy ideas. Someone is working on a VFS based on Foundation DB[0] that looks very promising. It was recently discussed here[1]
[0]: https://github.com/losfair/mvsqlite
[1]: https://news.ycombinator.com/item?id=32269287
- GitHub - losfair/mvsqlite: Distributed, MVCC SQLite that runs on FoundationDB.
What are some alternatives?
StorX-API - A REST API for StorX
dqlite - Embeddable, replicated and fault-tolerant SQL engine.
sqld - LibSQL with extended capabilities like HTTP protocol, replication, and more.
awesome-sqlite - A curated list of awesome things related to SQLite
libsql - libSQL is a fork of SQLite that is both Open Source, and Open Contributions.
litefs - FUSE-based file system for replicating SQLite databases across a cluster of machines
configinator
rqlite - The lightweight, distributed relational database built on SQLite.
zfs-autosnap - Minimal viable ZFS autosnapshot tool
datasette-stripe - A web SQL interface to your Stripe account using Datasette.
roapi - Create full-fledged APIs for slowly moving datasets without writing a single line of code.
blueboat - All-in-one, multi-tenant serverless JavaScript runtime.