Seems great on paper, but quickly turns into a nightmare. Magic is great to get you up to speed, but as soon as you find yourself having to bend the magic, good luck.
This is clearly low quality, non-idiomatic AI-generated Elixir code. So the likely answer is that "you" did not use this at all; AI did.
I review this kind of AI-generated Elixir code on a daily basis. And it makes me want to go back to ~2022, when code in pull requests actually made sense.
Apologies for the rant, this is just a burnt out developer tired of reviewing this kind of code.
PS: companies should definitely highlight "No low-quality AI code" in job listings as a valid perk.
Coincidentally I'm working on FeebDB[0], which is similar but for Elixir instead. It can be seen as a replacement to Ecto (which won't work well when you have thousands of databases).
Mostly as a fun experiment, but also from the realization that every place I worked at in the past (small/medium-sized B2B startups) would greatly benefit from such architecture.
Yes, there are massive trade-offs to this approach, and the concerns raised in the comment section are valid. This doesn't mean the database-per-tenant is never worth it. There's a sweet spot for it, and if it fits your business/application, I personally would consider it a technical advantage over competitors.
My goal with FeebDB is to eliminate or reduce the common pain points of database-per-tenant, including:
- ensure there is a single writer per database.
- improved connection management across all tenants (e.g. only keep open at most 1000 DB connections, similar to an LRU cache).
- on-demand migration (all shards are migrated on application startup, but if a shard that hasn't migrated yet receives a request, it will first perform the migration and then serve the request),
- on-demand backups and replication (e.g. the library knows which shards were updated in the last X minutes, so it can trigger Litestream or similar on demand).
- support for enumeration of databases (performing map/reduce/filter operations across multiple DBs)
- support for clustered deployment with "pinned" tenants (for now I'm assuming the IOPS of a single beefy server should be enough for all use cases, but once that's no longer sufficient you can have "shards of shards")
I think we are beyond the "theory" phase by now. Just yesterday I saw the president of a country advertising the products of a private company (Trump making an obvious marketing ploy for Tesla).
The failure relative to the original expectations seems to be that the other branches of government aren't fighting to retain their authority because the things they're being overridden to do align too well with what they would do themselves.
> the president of a country advertising the products of a private company
I think you're inventing new norms. It has never been unusual or interesting for the president of a country to do PR for some company in their country that has hit a rough patch (as long as this isn't a legal rough patch.)
Most of what our diplomats do is sell US products to other countries. They certainly have always played favorites.
> How can this ever be acceptable?
The horror. What if he says that he's going to Burger King?
(PS: they opted to go in a direction where it also includes some media-related features -- like tracking movies or books you've seen/read -- but this can be disabled).
If you navigate straight to bad-domain.com which redirects to good-domain.com, there will be no referer at all.
If you click a link on red-herring.com which points to bad-domain.com, which then redirects to good-domain.com, the referer will be red-herring.com (if not disabled entirely).
I just tested on firefox and it doesn't send the "Origin" header when using referrerpolicy="no-referrer". It's also not present when navigating using the url bar directly.
I didn't say it was. Browsers display an alert when full-screen mode is activated. Full-screen mode isn't a security feature, but the browser does something the website developer can't control so that users can conclude that something fishy isn't going on. I think the ability for one website to hide that they've redirected to another is a vulnerability.
I'm inclined to agree that websites should know when they're the target of a redirect but that has nothing to do with Referer! That header does not work the way so many seem to think it does. As I've laid out elsewhere in this thread, HTTP redirects do not show up in Referer under any circumstances. Right now, one site doesn't have to do anything to "hide" that it's part of a redirect chain, since there's no tracking of that chain to begin with.
Additionally, a break might be an opportunity for your mind to continue working on whatever it was you left off with, whereas an interruption explicitly redirects your attention to another topic.
When I’m deep in the weeds on a task, stepping away for a walk in the park, a workout, or to prepare a meal or some coffee, affords me the opportunity to clear the micro details of the task from my mind while retaining the macro at the tip of my attention. This state is very frequently where the best insights on the task emerge, whereas an interruption resets both micro and macro attention entirely to something else.
A hobby project of mine (in Elixir) uses SQLite as primary database. Each test runs in its own fully isolated SQLite database. No mocking (or transaction rolling back) needed. Most of these tests take less than 1ms to run (and when they take longer, it's because of something else).
This kind of setup makes the usual Ecto Sandbox approach feel slow, but I do agree that the way Elixir approaches this is great!
I actually have two projects that use this approach, FeebDB (which is the library I wrote to manage a "one SQLite database per client" approach) and HackerExperience (a game under development that uses FeebDB).
The overall idea is simple:
1. Before tests start running, create a prop of each database.
2. The prop contains the "starting database" for each test. It may contain seed data (optional).
3. For each test, copy the prop and assign it a unique shard identifier (say, cp /props/user.db /test_data/user/874125.db).
4. The test knows the `shard_id` and can do whatever it wants with it; no one else will bother it.
5. Once ExUnit is finished, delete all shards.
Both projects follow a similar approach (I wrote it first in FeebDB and copied into HackerExperience, which has some sections commented out -- I need to clean up this part of the codebase).
For both projects, you will find steps 1/5 in `test/support/db.ex`, step 2 in `test/support/db/prop.ex` and steps 3/4 in `test/support/case/db.ex`.
Seems great on paper, but quickly turns into a nightmare. Magic is great to get you up to speed, but as soon as you find yourself having to bend the magic, good luck.