You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the default behavior of this extension is sending every read query to the replica(s) and every write to the primary. While you can opt-in to using the primary with $primary() , it's default is to always use the replicas for any read. In my opinion, this is a dangerous and unintuitive default, as replication lag could cause unexpected behavior for users if they immediately try to access a newly inserted row after a write.
To mitigate this, a safer default would be to send all reads and writes to primaries by default. This way, there is a guarantee that the reads after writes will always be available. When the user wants to explicitly use replicas, they should call the $replicas() method and chain their queries to it, so this way they are knowingly opting into relaxed consistency and accepting the replication lag that comes with it.
For reference, this is how a lot of other frameworks/ORMs do it. See Django and Rails for example.
The text was updated successfully, but these errors were encountered:
+1, came to note the same thing. This is about six months old now. Do we any updates as to whether this will be addressed? We want to issue queries to the read replica but the only other solution is to have a second Prisma client.
Currently, the default behavior of this extension is sending every read query to the replica(s) and every write to the primary. While you can opt-in to using the primary with
$primary()
, it's default is to always use the replicas for any read. In my opinion, this is a dangerous and unintuitive default, as replication lag could cause unexpected behavior for users if they immediately try to access a newly inserted row after a write.To mitigate this, a safer default would be to send all reads and writes to primaries by default. This way, there is a guarantee that the reads after writes will always be available. When the user wants to explicitly use replicas, they should call the
$replicas()
method and chain their queries to it, so this way they are knowingly opting into relaxed consistency and accepting the replication lag that comes with it.For reference, this is how a lot of other frameworks/ORMs do it. See Django and Rails for example.
The text was updated successfully, but these errors were encountered: