www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - vibe-mongodriver 1.0.1: MongoDB 8 driver for D

reply Bogdan Szabo <contact szabobogdan.com> writes:
I have released vibe-mongodriver 1.0.1, a MongoDB client for D 
supporting servers up to 8.0. It started as MongoDB work inside a 
fork of vibe.d and outgrew it. I opened pull requests upstream 
but have not had feedback on them, and a rewrite spanning this 
many commits was unlikely to land as a single change anyway. 
Missing support for recent MongoDB versions is a common reason to 
pass on vibe.d, so rather than leave the work sitting in a 
private fork, I am releasing it as a separate package.


Beyond vibe-d:mongodb, it adds Server Discovery and Monitoring, 
replica set and sharded topologies, load-balanced mode, 
mongodb+srv seedlists, transactions with pooled sessions, causal 
consistency, retryable writes, change streams, GridFS, 
client-side field-level encryption, MongoDB 8 bulkWrite, wire 
compression, and SCRAM-SHA-256 and X.509 authentication. CI runs 
the integration suite against MongoDB 3.6 through 8.0. The API is 
unchanged, so migration is one sed 
(s/vibe\.db\.mongo\b/vibe.db.mongodriver/g), and since only 
module names differ, both packages can link into the same binary, 
letting a large codebase migrate incrementally.

MIT licensed, original vibe.d history preserved.

https://code.dlang.org/packages/vibe-mongodriver
https://gitlab.com/GISCollective/vibe-mongodriver
Jul 28
next sibling parent reply Anton Pastukhov <mail anton9.com> writes:
On Tuesday, 28 July 2026 at 08:11:23 UTC, Bogdan Szabo wrote:

 I have released vibe-mongodriver 1.0.1, a MongoDB client for D


Took me a moment to realize that "vibe" here is related to 
vibe.d, not vibe-coding.

The word "vibe" has completely changed its meaning since the 
inception of vibe.d. It now has a strong "vibe-coding" 
connotation, and I'm pretty sure people don't want their DB 
drivers to be vibecoded. If you decided to roll with this name, 
maybe at least add a prominent disclaimer to the readme?
Aug 04
parent Bogdan Szabo <contact szabobogdan.com> writes:
On Tuesday, 4 August 2026 at 11:02:32 UTC, Anton Pastukhov wrote:

 On Tuesday, 28 July 2026 at 08:11:23 UTC, Bogdan Szabo wrote:

 I have released vibe-mongodriver 1.0.1, a MongoDB client for D


 Took me a moment to realize that "vibe" here is related to 
 vibe.d, not vibe-coding.

 The word "vibe" has completely changed its meaning since the 
 inception of vibe.d. It now has a strong "vibe-coding" 
 connotation, and I'm pretty sure people don't want their DB 
 drivers to be vibecoded. If you decided to roll with this name, 
 maybe at least add a prominent disclaimer to the readme?


Keeping the name. It follows the ecosystem convention (vibe-core, 
vibe-http) and it says what the library is built on. If "vibe" is 
now a problem word, that's a conversation about vibe.d, not about 
one driver.

And I'm not chasing adoption here. The announcement exists so 
anyone who needs a MongoDB client for D knows the work is done. 
Anyone who actually needs it will open the repo, and the code 
speaks for itself.
Aug 06
prev sibling parent reply =?UTF-8?Q?S=C3=B6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 28.07.26 um 10:11 schrieb Bogdan Szabo:

 I have released vibe-mongodriver 1.0.1, a MongoDB client for D 
 supporting servers up to 8.0. It started as MongoDB work inside a fork 
 of vibe.d and outgrew it. I opened pull requests upstream but have not 
 had feedback on them, and a rewrite spanning this many commits was 
 unlikely to land as a single change anyway. Missing support for recent 
 MongoDB versions is a common reason to pass on vibe.d, so rather than 
 leave the work sitting in a private fork, I am releasing it as a 
 separate package.
 
 
 Beyond vibe-d:mongodb, it adds Server Discovery and Monitoring, replica 
 set and sharded topologies, load-balanced mode, mongodb+srv seedlists, 
 transactions with pooled sessions, causal consistency, retryable writes, 
 change streams, GridFS, client-side field-level encryption, MongoDB 8 
 bulkWrite, wire compression, and SCRAM-SHA-256 and X.509 authentication. 
 CI runs the integration suite against MongoDB 3.6 through 8.0. The API 
 is unchanged, so migration is one sed (s/vibe\.db\.mongo\b/ 
 vibe.db.mongodriver/g), and since only module names differ, both 
 packages can link into the same binary, letting a large codebase migrate 
 incrementally.
 
 MIT licensed, original vibe.d history preserved.
 
 https://code.dlang.org/packages/vibe-mongodriver
 https://gitlab.com/GISCollective/vibe-mongodriver


I'm sorry that the reviews kind of starved. I really tried to allocate 
time for it, but the amount of changes is just beyond what I can 
realistically review and I never made it to the end of the largest PR. 
However, all the changes I've seen so far were of high quality.

What I'm thinking is that it might make sense to make this the first 
version of an official standalone MongoDB driver package (I had planned 
to move the code to a separate repository anyway) - so it would keep the 
original package name (vibe.db.mongo) and the vibe.d main package would 
be modified to enable opting in to use the new standalone package 
instead of the existing code in the main vibe.d repository. That way we 
could get good real-world exposure of the new code while keeping the old 
code available in case there are any unforeseen breaking changes. 
Eventually, the old code could then just be removed.

What do you think?
Aug 14
next sibling parent reply Mindy Batek (0xEAB) <desisma heidel.beer> writes:
On Friday, 14 August 2026 at 12:37:28 UTC, Sönke Ludwig wrote:

 What do you think?


Monorepos are nice.
Aug 14
parent =?UTF-8?Q?S=C3=B6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 14.08.26 um 19:20 schrieb Mindy Batek (0xEAB):

 On Friday, 14 August 2026 at 12:37:28 UTC, Sönke Ludwig wrote:

 What do you think?


 
 Monorepos are nice.


The main problem is that the complete library changes in a very 
heterogeneous way. Some parts have a really stable API and other parts 
still have relatively frequent and sometimes breaking changes. Having 
them together as one repository means that there are frequent 
major/minor version bumps that need to be handled in dependent code, 
even if that only depends on the stable parts.

Otherwise I agree, having everything together simplifies things quite a bit.
Aug 15
prev sibling parent Bogdan Szabo <contact szabobogdan.com> writes:
On Friday, 14 August 2026 at 12:37:28 UTC, Sönke Ludwig wrote:

 Am 28.07.26 um 10:11 schrieb Bogdan Szabo:

 I have released vibe-mongodriver 1.0.1, a MongoDB client for D 
 supporting servers up to 8.0. It started as MongoDB work 
 inside a fork of vibe.d and outgrew it. I opened pull requests 
 upstream but have not had feedback on them, and a rewrite 
 spanning this many commits was unlikely to land as a single 
 change anyway. Missing support for recent MongoDB versions is 
 a common reason to pass on vibe.d, so rather than leave the 
 work sitting in a private fork, I am releasing it as a 
 separate package.
 
 
 Beyond vibe-d:mongodb, it adds Server Discovery and 
 Monitoring, replica set and sharded topologies, load-balanced 
 mode, mongodb+srv seedlists, transactions with pooled 
 sessions, causal consistency, retryable writes, change 
 streams, GridFS, client-side field-level encryption, MongoDB 8 
 bulkWrite, wire compression, and SCRAM-SHA-256 and X.509 
 authentication. CI runs the integration suite against MongoDB 
 3.6 through 8.0. The API is unchanged, so migration is one sed 
 (s/vibe\.db\.mongo\b/ vibe.db.mongodriver/g), and since only 
 module names differ, both packages can link into the same 
 binary, letting a large codebase migrate incrementally.
 
 MIT licensed, original vibe.d history preserved.
 
 https://code.dlang.org/packages/vibe-mongodriver
 https://gitlab.com/GISCollective/vibe-mongodriver


 I'm sorry that the reviews kind of starved. I really tried to 
 allocate time for it, but the amount of changes is just beyond 
 what I can realistically review and I never made it to the end 
 of the largest PR. However, all the changes I've seen so far 
 were of high quality.

 What I'm thinking is that it might make sense to make this the 
 first version of an official standalone MongoDB driver package 
 (I had planned to move the code to a separate repository 
 anyway) - so it would keep the original package name 
 (vibe.db.mongo) and the vibe.d main package would be modified 
 to enable opting in to use the new standalone package instead 
 of the existing code in the main vibe.d repository. That way we 
 could get good real-world exposure of the new code while 
 keeping the old code available in case there are any unforeseen 
 breaking changes. Eventually, the old code could then just be 
 removed.

 What do you think?


Yeah, I totally get this. Same on my side; work and family take a 
lot of time, and I don't have time to focus on public 
contributions as I did in the past.

I am currently using the fork in production already, but with 
only one DB server, no shards or replicas, and it works great so 
far. Atlas and replicas are a thing for the future to fully test 
on a real prod env once I have more budget on GISCollective, but 
it worked great on my local setup anyway, even though there might 
be issues (which, if anyone finds, I will do my best to fix, 
because this lib is one of the core libs that I use).

I'm fine with making this package official; I can prepare all the 
imports and such, but I would like to be able to contribute to it 
even if it gets moved to the vibe.d organisation.

Let me know the best way to collaborate, and I'll make the 
changes.

Bogdan
Aug 16