Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quick question #1

Open
dariusc93 opened this issue Jan 17, 2021 · 1 comment
Open

Quick question #1

dariusc93 opened this issue Jan 17, 2021 · 1 comment
Labels
question Further information is requested

Comments

@dariusc93
Copy link

Found your library while checking the version for mongo and I must say I am impressed. I used to just have a trait that I would use to implement a struct that would represent the collection before using another library that, in a way, simplified it abit more (it was wither) but that from my knowledge is out dated until they update to the official mongodb library.

I would like to know what features would be missing from the crate? I havent used it yet but do plan on implementing it into my application and giving a test run but just curious since in your TODO that it says not all features have been implemented.

@alexkornitzer
Copy link
Contributor

Ah so that is laziness on my part I should have documented the TODOs a little better.

In a sense all features are accessible as you can expose and use the original mongo client for the parts that have not been wrapped in this crate, but to list things that are not in that immediately come to my mind:

  • A couple of query functions are yet to be implemented as query builders such as the aggregate function on a Collection
  • The blocking client has not been implemented for Database and some functions in Collection

I have probably missed some from the above but for the first version of this wrapper we went for the common queries first just in case we need to tweak the design.

The reason for the multi trait breakdown is due to the desire to strongly type the queries, i.e. you can't use collection Bs filter on collection A, you can't get insert a document of type B into A collection, etc. By having this breakdown it prevents the need for certain types to be derived if you are only going to interact with collections in certain ways, or if the derive is not powerful enough and the type must be implemented by hand.

Any feedback is greatly welcomed as we will not have accounted for everything and are happy to see how it can be improved.

@alexkornitzer alexkornitzer added the question Further information is requested label Jan 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants