Should most database operations be made to take `&self` and not `&mut self`?

[emchristiansen]

Should most database operations be made to take `&self` and not `&mut self`?

[ohsayan]

The underlying connection type would need a mutable reference to write any data (see impl and definition for the Write and AsyncWrite traits), which is why the actions accept mutable references. In Rust, mutable references are mutually exclusive to immutable references (so you can have a single &mut T or multiple &Ts).

Regarding sending queries concurrently (and assuming you do not mean parallelism), in this library-specific scenario, you can utilize pipelining to send multiple queries at the same time. Multiplexed queries are still experimental (and not available for public use right now).

[ohsayan]

If you wanted to utilize multiple threads for sending queries, considering looking at the available connection pool implementations: https://docs.rs/skytable/latest/skytable/pool/index.html

[emchristiansen]

You're referring to, e.g., AsyncWrite here?

client-rust/src/lib.rs

Line 426 in c57e46e

impl<T: AsyncWrite + Unpin + Send + Sync> WriteQueryAsync<T> for Query {

I see that you're mutating stream in implementing tokio::io::AsyncWrite, and that forces the existence of an &mut.
But maybe you could use a mutex here to serialize the writes, so the API one level up wouldn't need to take an &mut?
If the writes are fast then serializing through a mutex might be very cheap, and it would make it much easier for the user to write concurrent code.

If this is unnecessary, could you prove it?
E.g. add an example to the examples folder that concurrently fetches 10000 i32s from a database of type (String, i32), increments each i32, then saves the results back to the database?
As a Rust noob I have no idea how to do that without having 10000 simultaneous connections, and even that approach isn't elegant.

[ohsayan]

maybe you could use a mutex here to serialize the writes

Using a mutex in a single threaded scenario would only waste time due to slower atomic instructions. In a multi-threaded scenario, you will not get any concurrency, since a mutex provides mutual exclusion, i.e only one thread will be able to use the connection at a time. If you wanted to share it, on top of that, you'll need to wrap it in an Arc to make it Send (since a mutex is !Send)

[ohsayan]

If the writes are fast then serializing through a mutex might be very cheap

Writing to a server over a network cannot be classified as a "fast" operation, especially when you're talking about synchronization

[ohsayan]

As a Rust noob I have no idea how to do that without having 10000 simultaneous connections, and even that approach isn't elegant.

You could:

• Pipeline it: if you wanted to use a single thread (so you send 10000 queries over the same connection in one go)
• Use a connection pool: Say spawn it with 10 threads and then send 10K queries over the 10 different connections (edit: reworded to avoid confusion)

[ohsayan]

I'll recommend you to read std's documentation on

• the sync module covering when to use Mutexes and other synchronization primitives: https://doc.rust-lang.org/stable/std/sync/index.html.
• the Send and Sync marker traits

Let me know if you have any other questions :)