Problem: Bad response when querying:

C:\Users\cmm\dev\local\skytest> cargo run  
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target\debug\skytest.exe`
Response: Item(Str("HEY!"))
Response: Item(Str("HEY!"))
Response: InvalidResponse
Response: InvalidResponse
Response: InvalidResponse
Response: Item(Str("HEY!"))
Response: InvalidResponse
Response: Item(RespCode(PacketError))
Response: InvalidResponse
Response: InvalidResponse
Response: Item(RespCode(PacketError))

Platform: Windows 10 Pro 20H2 skyd 0.5.2 and 0.5.1

I tried this: Cargo.toml

[package]
name = "skytest"
version = "0.1.0"
edition = "2018"

[dependencies]
skytable = "0.2.3"
tokio = {version="1.5.0", features=["full"]}

main.rs

use skytable::{Connection, Query};

#[tokio::main]
async fn main() -> std::io::Result<()> {
    let mut con = Connection::new("127.0.0.1", 2003).await?;
    loop {
        let mut query = Query::new();
        query.arg("heya");
        let response = con.run_simple_query(query).await?;
        println!("Response: {:?}", response);
        std::thread::sleep(std::time::Duration::from_millis(200));
    }
}

I'm a relative Rust noob so this question may be off-base, but I noticed that most of the database operations take mutable references to the database, e.g. get uses this codepath: https://github.com/skytable/client-rust/blob/d6ca102e4c74dc7797d8639bf85ae42436f42584/src/actions.rs#L119

As I said I'm a noob, but this makes it very hard (impossible?) to send several requests concurrently over the same connection, because Rust only lets at most one mutable borrow exist for a given object at any time.

For comparison, RocksDB (which also allows concurrent access) treats most database operations as non-mutating, making it substantially easier to use with futures, e.g.: https://github.com/rust-rocksdb/rust-rocksdb/blob/b5b9e56d084aec2460bb50851757519b0387e198/src/db.rs#L939

If I'm wrong and it is easy to spin off dozens of concurrent futures which interact with the database, could you add such an example to the examples folder? If not, consider marking these methods as non-mutable?

Thank you for your work on SkyTable. When looking at the Rust Client, I noticed the current example code, did not compile because of the Result return type.

use skytable::{Connection, Query, Element}; fn main() -> std::io::Result<()> { let mut con = Connection::new("127.0.0.1", 2003)?; Ok(()) }

I updated the example to use 'SkyResult' instead.

Thank you Nelius

Currently Query::arg exists in order to add a String to a Query, this works really well with something like serde_json. However, it would be really convenient to also be able to add a Vec<u8> or similar directly to a Query in order to store a binary blob using something like bincode to serialize the data.

If you're following skytable/skytable#148, Skytable is officially EOL-ing Terrapipe and introducing a new serialization protocol Skyhash. This issue serves to track our progress of upgrading to the Skyhash protocol

This is just a code sketch, as I'm a bit unclear on a couple things:

1. I'm not sure why this wasn't already included (and I assume you have a good reason).
2. I don't understand why you're encoding the key / value data the way you are. For example, in line 475 you seem to assume primitives are encoded as UTF8 strings, which seems very odd. Rather I'd expect everything in the DB to be (arbitrary, not UTF8) Vec<u8>s. I think you can convert all these primitives to bytes using functions like _.to_le_bytes().

Relatedly, I'm not sure why you need the RawString type instead of just implementing the appropriate traits for Vec<u8>.

There's an impl IntoSkyhashBytes for RawString but no impl FromSkyhashBytes for RawString, and I do not understand why. Can you either add this or add a note explaining why it doesn't make sense?

Thanks!

I see for the normal async there is a way to get the entity you wish to connect to. But for the async pool, there isn't.

I could run a switch on every connection, but since it seems to send something to server, I am guessing there is a penalty? It would be nice if we can have the connections in the pool be able to be set with whichever entity/table we wish to use.

Or maybe better assign a certain amount of connections per entity/table? This way it would avoid the penalty for lookup when switching? (unless the penalty isn't per connection/session?)

Also, a little side comment. Not sure if you prefer it as a separate issue or here is fine. But the docker "latest" and "next" are the same thing (v0.8) where as latest should be v0.7.5. It also may make more sense to have smaller builds debian-slim / almalinux-minimum / almalinux-micro / alpine linux(if there is no issue with musl) instead of just the full stable build.