JSON column to struct

[trentclowater]

What is the best way, using bob, create a model that transforms the contents of a jsonb column in the database into a struct in the model? (I'm using Postgres if that makes any difference).

For example, if there is a history table with a column named network, with contents like:

[
    {
        "key": "interface",
        "name": "Network Interface",
        "values": [
            {
                "key": "mac_address",
                "name": "MAC Address",
                "value": "00:01:02:03:04:05"
            }
        ]
    },
    {
        "key": "interface",
        "name": "Network Interface",
        "values": [
            {
                "key": "mac_address",
                "name": "MAC Address",
                "value": "01:02:03:04:05:06"
            }
        ]
    }
]

I would like the generated models.History to look like this:

type History struct {
  ID int64
  Network []Item
}

type Item struct {
	Key    string `json:"key"`
	Name   string `json:"name"`
	Values []Value `json:"values"`
}

type Value struct {
	Key   string `json:"key"`
	Name  string `json:"name"`
	Value string `json:"value"`
}

So that instead of Network being types.JSON[json.RawMessage], it gets unmarshalled into a struct. Is that even possible? Or am I thinking about this the wrong way, and I should be doing something else?

[jacobmolby]

You can try something like this:

package mytypes

type History struct {
	ID      int64
	Network []Item
}

type Item struct {
	Key    string  `json:"key"`
	Name   string  `json:"name"`
	Values []Value `json:"values"`
}

type Value struct {
	Key   string `json:"key"`
	Name  string `json:"name"`
	Value string `json:"value"`
}

func (h *History) Scan(value any) error {
	bytes, ok := value.([]byte)
	if !ok {
		return fmt.Errorf("value is not []byte")
	}

        return json.Unmarshal(bytes, &h)
}

func (h History) Value() (driver.Value, error) {
	return json.Marshal(h)
}

Then in your bobgen config file you should do the following:

types:
  mytypes.History:
    no_randomization_test: true
    imports: ['mytypes "abc/mytypes"']
    random_expr: |
      return mytypes.History{}
    compare_expr: |-
      reflect.DeepEqual(AAA, BBB)
    compare_expr_imports: ['"reflect"']

replacements:
  - tables: ["my_table"]
     match: 
          name: "history"
    replace: "mytypes.History"

[stephenafamo]

This is the recommended approach 👍🏾

[trentclowater]

Thanks for the answer. I had about 99% of that correct already.

The problem turned out to be that I thought the nullable parameter in the replacements match was just to increase specificity of matching (i.e. if no table name was given and it matches a column name in multiple tables, but you only want the replacement to run for the matches on NULL columns).

But it seems that nullable: true is required to match a NULL column, even if there is only one possible match. In my case, I was specifying the table name and column name, so I thought that just using the table name should match the column I expected it to match.

That was not really clear from the documentation, and I left it out of the question because I thought I could just make the custom type null.Val[MyType] directly in the config file. I didn't realize that the nullable: true would wrap the custom type in null.Val automatically.

Also, I noticed I made a typo and typed table instead of tables in replacements, and that seem to work fine. Not sure if those are identical in practice, or if there is some difference, just something I noticed.

[jacobmolby]

Arh, yes. You need to be aware of that. I didn't realize it myself initially, which is why this PR: #91 was made.

I guess it could be changed so you explicitly have to set the nullable value instead of it defaulting to false.

[trentclowater]

I just wrote my original, non-working code again, and now I see the error message when I look for it. It's printing at the beginning of the output, so I didn't actually see it originally because it got scrolled off-screen, and everything that was visible on-screen made it look like everything worked correctly.

I looked at the diff of the PR, and I can see that if you hadn't added that, I would have never even thought to experiment with the nullable parameter at all. It might be more clear if the comment was something like "Match nullable columns, and wrap replacement type with null.Val. Defaults to false."

Or your idea of having to explicitly set it also has merits. It might make it more clear that it is not increasing the specificity of the match, but is actually an integral part of the match.