作者：湖黯之殇_257 | 来源：互联网 | 2023-06-01 14:31
I ended up adding separate APIs for creating collections and views even though both use the same1cre
I ended up adding separate APIs for creating collections and views even though both use the same
command under the hood because the command doesn't have great separation of concerns. A lot of the server options (e.g. capped, valdiator, etc) do not apply when creating a view, so separate APIs made sense to me. This is also in line with what mgo did. In scope of this ticket, I also added embedded documentation examples and switched the integration testing library to use the new APIs rather than
to create collections.
The main open question is whether or not we should include options like
, which was deprecated in 3.2 and removed in 4.0 for all databases besides "local". I included it becuase we still support 2.6 and 3.0, even though those have been EOLed.
该提问来源于开源项目：mongodb/mongo-go-driver
Ah I see, I did not realise
is not part of the driver. That's a big bummer. It makes sense to me to implement it at the application level; what if I want to change my document scheme, run a migration process to update existing documents to the new scheme, and then update the validation?
Is it not worth considering adding an
or
1
| updateCollectionValidation |
that can update the validation of a collection? Since creating collection with validation is already part of the 1.4.0 driver it might not be too much of a hassle?
京公网安备 11010802041100号