Generate new ObjectID only when required#1479
Conversation
|
any plans on the fate of this PR? thanks |
API Change ReportNo changes found! |
1321a0c to
4cfa230
Compare
There was a problem hiding this comment.
Hi @adhocore , thank you for this contribution. I noticed when testing this that we do not have a benchmark for NewObjectID(). Would mind adding one in the bson/primitive/object_test.go file?
func BenchmarkNewObjectIDFromTimestamp(b *testing.B) {
for i := 0; i < b.N; i++ {
timestamp := time.Now().Add(time.Duration(i) * time.Millisecond)
_ = NewObjectIDFromTimestamp(timestamp)
}
}We should also update the comment for ensureID to match the new behavior:
// ensureID inserts the given ObjectID as an element named "_id" at the
// beginning of the given BSON document if there is not an "_id" already. If
// the given ObjectID is primitive.NilObjectID, a new object ID will be
// generated with time.Now().
//
// If there is already an element named "_id", the document is not modified. It
// returns the resulting document and the decoded Go value of the "_id" element.Also, we would like to test this use case more closely. There already exists a test for ensureID, found here. However, it's not quite written to deal with this change. So I would suggest adding another test validating this specific usage:
func TestEnsureID_NilObjectID(t *testing.T) {
t.Parallel()
doc := bsoncore.NewDocumentBuilder().
AppendString("foo", "bar").
Build()
got, gotIDI, err := ensureID(doc, primitive.NilObjectID, nil, nil)
assert.NoError(t, err)
gotID, ok := gotIDI.(primitive.ObjectID)
assert.True(t, ok)
assert.NotEqual(t, primitive.NilObjectID, gotID)
want := bsoncore.NewDocumentBuilder().
AppendObjectID("_id", gotID).
AppendString("foo", "bar").
Build()
assert.Equal(t, want, got)
}|
thanks for feedback. will take a look into that asap :) |
|
updated accordingly. the TestEnsureID_NilObjectID test run looks like: and the benchmark looks like: |
7003d7f to
af7dd71
Compare
(cherry picked from commit 820366e)
Summary
any insert operation preemptively generates new ObjectID to check/ensure if
_idexists in doc or not - but chances are that goes to waste. this waste is more pronounced in scenarios where _id is a mix of custom userland id and system generated one across collections of a db or even across documents of same collectionsnippet
output before (4 wastes)
output after (no wastes)
Background & Motivation
ID burning is a thing in sql world, while this one is different world here, i believe it does not hurt to be cautious of resource we use/disuse. quoting from summary above:
isn't it more logical to generate it if only we ever really need it?