Re: [go-nuts] Go type assertion for MongoDB []bson.M{}/primitive.A type

Something like this: type Author struct { ID primitive.ObjectID `bson:"_id"` CreatedAt time.Time `bson:"created_at"` ... } type Data struct { Author []Author `bson:"author"` } Then you read the results into var result []Data On Thu, Nov 16, 2023 at 10:39 AM Tong Sun wrote: > >

Re: [go-nuts] Go type assertion for MongoDB []bson.M{}/primitive.A type

Thanks for the hint. would you elaborate a bit more please as I'm still unsure how to do it. and the closes hits that I found are - https://stackoverflow.com/questions/71739971/unmarshalling-a-bson-d-object-golang - https://www.mongodb.com/docs/drivers/go/current/fundamentals/bson/

Re: [go-nuts] Go type assertion for MongoDB []bson.M{}/primitive.A type

val["author"].(primitive.A)[0] is correct, but the type of that expression is not author, it is bson.M. You might consider using a tagged struct to unmarshal this. On Thu, Nov 16, 2023 at 10:11 AM Tong Sun wrote: > > Further on with the question >

[go-nuts] Go type assertion for MongoDB []bson.M{}/primitive.A type

Further on with the question https://stackoverflow.com/questions/60072372/filtering-values-out-of-a-bson-m-in-golang/ where the answer says to use `range server.installed` while the comment says server.host undefined (type string has no field or method subject) This is what I've tried with the

Re: [go-nuts] Go http/2 ClientConn readLoop use more memory than http/1.1

> Is this an expected result that with http/2, that we will be using more > memory at the cost of multiplexing and streaming? Or am I missing something > here? They’re very different protocols, so it’s often not useful to directly compare. There are aspects of http/2 (eg. hpack state) that

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

You may forgive me. El jue, 16 nov 2023 a las 11:57, Mike Schinkel () escribió: > On Thursday, November 16, 2023 at 9:16:22 AM UTC-5 Victor Giordano wrote: > > Lads, I guess this entry and the > subsequent entries are very important regarding the discussion. >

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

On Thursday, November 16, 2023 at 9:16:22 AM UTC-5 Victor Giordano wrote: Lads, I guess this entry and the subsequent entries are very important regarding the discussion. *Also we shall recall that T and *T are different types. * *Golang performs some implicit

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

Regarding the Original question: I guess the advice of using a pointer receiver can be OK as long you know what you are coding. quoting "https://go.dev/tour/methods/8; > There are two reasons to use a pointer receiver. > The first is so that the method can modify the value that its receiver

[go-nuts] Re: Go-native abstract service interface design

Upon reflection, I would make the following improvements to bring the interfaces closer to Go's philosophical ideals: * Remove the App interface because it only has one implementation * Remove the Named interface because all its usages seem to be replaceable with a package-scoped const * Split