actix/actix-extras
1
0
Fork 0
mirror of https://github.com/actix/actix-extras.git synced 2024-11-24 07:53:00 +01:00
Code Issues Releases Wiki Activity

Guide: updates to the Database integration chapter.

Browse Source
This commit is contained in:
memoryruins 2018-04-06 19:02:11 -04:00
parent e7f9f5b46d
commit 0f0fe5f148
1 changed files with 18 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
guide/src/qs_14.md
View File

@ -2,13 +2,14 @@
## Diesel
At the moment of 1.0 release Diesel does not support asynchronous operations.
But it possible to use the `actix` synchronous actor system as a db interface api.
Technically sync actors are worker style actors, multiple of them
can be run in parallel and process messages from same queue (sync actors work in mpsc mode).
At the moment, Diesel 1.0 does not support asynchronous operations,
but it possible to use the `actix` synchronous actor system as a database interface api.
Let's create a simple db api that can insert a new user row into an SQLite table.
We have to define sync actor and connection that this actor will use. The same approach
Technically, sync actors are worker style actors. Multiple sync actors
can be run in parallel and process messages from same queue. Sync actors work in mpsc mode.
Let's create a simple database api that can insert a new user row into a SQLite table.
We must define a sync actor and a connection that this actor will use. The same approach
can be used for other databases.
```rust,ignore
@ -21,7 +22,7 @@ impl Actor for DbExecutor {
}
```
This is the definition of our actor. Now we need to define the *create user* message and response.
This is the definition of our actor. Now, we must define the *create user* message and response.
```rust,ignore
struct CreateUser {
@ -33,8 +34,8 @@ impl Message for CreateUser {
}
```
We can send a `CreateUser` message to the `DbExecutor` actor, and as a result we get a
`User` model instance. Now we need to define the actual handler implementation for this message.
We can send a `CreateUser` message to the `DbExecutor` actor, and as a result, we receive a
`User` model instance. Next, we must define the handler implementation for this message.
```rust,ignore
impl Handler<CreateUser> for DbExecutor {
@ -67,7 +68,7 @@ impl Handler<CreateUser> for DbExecutor {
}
```
That's it. Now we can use the *DbExecutor* actor from any http handler or middleware.
That's it! Now, we can use the *DbExecutor* actor from any http handler or middleware.
All we need is to start *DbExecutor* actors and store the address in a state where http handler
can access it.
@ -97,9 +98,9 @@ fn main() {
}
```
And finally we can use the address in a request handler. We get a message response
asynchronously, so the handler needs to return a future object, also `Route::a()` needs to be
used for async handler registration.
Finally, we use the address in a request handler. We receive the message response
asynchronously, thus the handler returns a future object.
`Route::a()` must be used for async handler registration.
```rust,ignore
@ -120,8 +121,8 @@ fn index(req: HttpRequest<State>) -> Box<Future<Item=HttpResponse, Error=Error>>
}
```
Full example is available in the
[examples directory](https://github.com/actix/actix-web/tree/master/examples/diesel/).
> A full example is available in the
> [examples directory](https://github.com/actix/actix-web/tree/master/examples/diesel/).
More information on sync actors can be found in the
[actix documentation](https://docs.rs/actix/0.5.0/actix/sync/index.html).
> More information on sync actors can be found in the
> [actix documentation](https://docs.rs/actix/0.5.0/actix/sync/index.html).