This article explores the behavior of the mgo/bson package that resets non-exported fields in Go structures to their zero values ??when deserializing BSON data. This mechanism is a built-in design of the mgo package to ensure deterministic deserialization results and cannot be disabled through configuration. The article will demonstrate this phenomenon through sample code and provide countermeasures.

mgo/bson.Unmarshal and zeroing of non-exported fields

When using labix.org/v2/mgo and its underlying labix.org/v2/mgo/bson package to deserialize BSON data from a MongoDB database into Go structures, a common phenomenon is that unexported fields in the target structure are reset to their zero values, even if these fields already contain data before deserialization. This means that bson.Unmarshal zeroes out the entire structure before populating the exported fields.

Consider the following Go struct definition and example code:

 package main

import (
    "fmt"
    "labix.org/v2/mgo/bson"
)

// Sub is an auxiliary structure containing exported fields type Sub struct{ Int int }

// Player structure contains exported field Name and non-exported fields unexpInt, unexpPoint
type Player struct {
    Name string
    unexpInt int // Non-exported integer field unexpPoint *Sub // Non-exported pointer field}

func main() {
    // Simulate the BSON data obtained from MongoDB, including only the Name field dta, err := bson.Marshal(bson.M{"name": "ANisus"})
    if err != nil {
        panic(err)
    }

    // Initialize the Player instance and assign the value p to the non-exported field:= &Player{unexpInt: 12, unexpPoint: &Sub{Int: 42}}

    fmt.Printf("Before Unmarshal: % v\n", p) //Print the status of p before deserialization //Execute BSON deserialization err = bson.Unmarshal(dta, p)
    if err != nil {
        panic(err)
    }
    fmt.Printf("After Unmarshal: % v\n", p) //Print the status of p after deserialization}

Running the above code, the output will clearly demonstrate this behavior:

 Before Unmarshal: &{Name: unexpInt:12 unexpPoint:0xc0000140a0}
After Unmarshal: &{Name:ANisus unexpInt:0 unexpPoint:<nil>}</nil>

As can be seen from the output, after the bson.Unmarshal operation, the Name field was correctly populated from the BSON data, but the unexpInt field changed from 12 to 0 (its zero value), and the unexpPoint field changed from a valid pointer to (its zero value).

Design principle: Why does Unmarshal clear non-exported fields?

This behavior is not a defect of mgo/bson, but is by design. According to the source code of the mgo/bson package (for example, in the decode.go file that handles struct deserialization), the value of the target struct is explicitly reset to its zero value before any fields are populated.

The main purpose of this design is to ensure that the result of the Unmarshal() operation depends only on the input BSON data and is not affected by any previous state of the target structure before Unmarshal is called. This ensures that the deserialization process is deterministic and predictable, avoiding potential data inconsistencies or difficulty in debugging caused by preset values ??for the target structure. In other words, mgo/bson aims to provide a "clean" deserialization operation so that each Unmarshal can build the result from a blank state.

Response Strategies and Best Practices

Since this is a built-in behavior of the mgo/bson package and no option is provided to disable it, we cannot directly prevent it from clearing non-exported fields. However, we can counter this mechanism with the following strategies:

1. Avoid relying on persistence of non-exported fields: The most straightforward solution is that if a field's value needs to be loaded from BSON data, or its value needs to be maintained during deserialization, then it should be designed as an exported field. Non-exported fields are typically used for internal state management and should not be expected to retain their values ??when external data is deserialized.

2. Processing data in stages: deserializing using temporary structures If your structure does contain exported fields that need to be loaded from BSON, and there are some non-exported fields that need to retain their original values ??or be populated from other sources, you can use the following method:

   • Define a temporary structure containing only all exported fields.
   • Deserialize BSON data into this temporary structure.
   • Then, manually copy the data in the temporary structure to your target structure instance, which preserves the original values ??of the non-exported fields in the target structure.

    // PlayerBSON is used for BSON deserialization and only contains exported fields type PlayerBSON struct {
       Name string `bson:"name"` // Make sure the field name matches the BSON document}
   
   func main_workaround() {
       dta, err := bson.Marshal(bson.M{"name": "ANisus"})
       if err != nil {
           panic(err)
       }
   
       p := &Player{unexpInt: 12, unexpPoint: &Sub{Int: 42}}
       fmt.Printf("Before Unmarshal (Workaround): % v\n", p)
   
       // 1. Create a temporary structure instance tempPlayerBSON := &PlayerBSON{}
   
       // 2. Deserialize BSON data into temporary structure err = bson.Unmarshal(dta, tempPlayerBSON)
       if err != nil {
           panic(err)
       }
   
       // 3. Copy the data of the temporary structure to the exported field p.Name = tempPlayerBSON.Name of the original Player instance
   
       fmt.Printf("After Unmarshal (Workaround): % v\n", p)
   }

   Running the main_workaround function, the output will be:

    Before Unmarshal (Workaround): &{Name: unexpInt:12 unexpPoint:0xc0000140e0}
   After Unmarshal (Workaround): &{Name:ANisus unexpInt:12 unexpPoint:0xc0000140e0}

   As you can see, the values ??of unexpInt and unexpPoint are successfully retained.

3. Post-processing: Repopulate non-exported fields after Unmarshal If the values ??of non-exported fields can be repopulated after Unmarshal by other means (for example, queried from the database, generated by calculations, or read from configuration), you can perform Unmarshal first and then perform a post-processing step to restore or set the values ??of these non-exported fields.

4. Use different structures for different purposes: for complex applications, you can define a structure specifically for database or network transmission (usually all fields are exported fields with BSON tags), and a structure for the application's internal business logic (can contain non-exported fields). Perform explicit conversions between these two structures as data enters or leaves the application boundary.

Summarize

When mgo/bson.Unmarshal deserializes BSON data, it first resets all fields of the target Go structure (including non-exported fields) to their zero values. This is a built-in design adopted by the mgo package to ensure the determinism of deserialization results, and cannot be disabled through configuration. Understanding this behavior is crucial to writing robust Go applications. Developers should respond effectively by avoiding relying on persistence of non-exported fields, using temporary structures for deserialization, or repopulating non-exported fields after deserialization, based on specific needs.

The above is the detailed content of mgo/bson.Unmarshal's processing mechanism and response strategies for non-exported fields. For more information, please follow other related articles on the PHP Chinese website!