inzanez

Quick addition: Another option would be to implement Deref and DerefMut for Document. This would be convenient as it would allow for things like this: ``` use std::ops::Deref; struct Document...

@arn-the-long-beard Well, I guess I would wait for @EpiFouloux as he's working on a proposal. But in general, it would be similar to what the current AQL query interface does....

@EpiFouloux Which one? Deref/DerefMut or removing the document struct?

@fMeow Ok, that's definitely a valid choice, as I already pointed out above. But I think it would make sense to emphasize that in the doucmentation / Readme as a...

Just as an idea: couldn‘t you just leave the `Document` structure in arangors, and change serialization of all collection methods to `T`? That way, every user of arangors could choose...

@EpiFouloux I think they (`_id`, `_rev` and `_key`) are being consumed as part of the deserialization process through `serde`. That's why I proposed to leave `Document` in the `arangors` crate,...

Oh, that‘s interesting. Well, but we would still have a deserialization to Document. Which would need to be unpacked...

But that still forces a user to unpack that Document,...couldn‘t that be optional? Or maybe add a second kind of functions on the collection that allows to use the functionality...

Could you not define a trait that exposed key, accept impl trait instead of Document struct, and just implement the trait for the internal Document type? That way, everyone that...

Just out of interest: I assume that supporting VelocyPack would bring performance boosts? Or is there more about it?