3 ms·
It's no different from any other deployment really. You have a single actor type in your init.sql then when you send in queries you always specify the same acto
by biokoda 10y ago
It's no different from any other deployment really. You have a single actor type in your init.sql then when you send in queries you always specify the same actor. It's easier to explain if you tell me what you don't understand.
- tyingq 10y agoIt's basically trying to figure out what the purpose of an "actor" is, and what it means in terms of schema design. I can't tell if I'm supposed to use multiple actors because it adds some kind of resilience, or performance, or something else? On the surface, it seems analogous to "CREATE DATABASE" / "USE DATABASE", but then the examples show applications using multiple actors...which wouldn't be typical (one app / multiple databases). So, it seems clear the idea is multiple actors within a single app, but what drives the choice of what the actors are? If the documentation started with some deeper explanation of actors, it might be easier to follow...as is, it jumps into actor syntax, creation, etc, without the reader really knowing what one is first. I do get that this might be unique to me...I'm just not grocking the concept.
- biokoda 10y agoIf you're an email host, an actor would be an email account. If you're dropbox/evernote/wunderlist, an actor would be a user account. If you're a payment processor, every payment would be an actor. If you're a messaging app, an actor would again be a user. If you have user groups, then every group would also be an actor. For your use case. An actor would be configuration for an app. If you have multiple apps (or services), they would have their own actors.