Decouple Go object marshaller/unmarshaller from Client about aerospike-client-go HOT 5 CLOSED

The reason it is integrated in the library is performance: BinMaps require memory allocation and garbage collection. We are heavily optimizing memory usage of both marshaling and unmarshaling operations.

Put/GetObject() methods save and retrieve a struct to/from the database with its attributes as bin names and values as bin values. Nested structs are automatically converted to maps. This is a very common use-case in application development.

JSON and Protobuf are unrelated to this purpose.

There are no compatibility issues with other languages, and there is no schema other than the struct.

from aerospike-client-go.

I see the point of GC optimization. If the BinPool is the only reason that couples Marshaller/Unmarshaller, We could let Client to expose a method to get bins from the pool. This is not a good design. But I think it's less harmful than Client integrates marshal/unmarshal logic, which may grow/change/deprecate and make Client bigger and possibly buggy. Baseline is that the higher level interface Put/GetObject() should sit on top of underlining database driver. It allows people to plug-in/replace other marshaller if they want.

I am also wondering the benefit to put top level struct's individual attributes into separate bins. Is there any plan to let users to update some attributes but not others? It seems not easy to provide that feature through plain Go struct. (Maybe use pointers for every attribute like proto 2 does, which is ugly and deprecated in proto 3). If not allowing user to change individual attribute/bin, what's the advantage over storing the entire struct in one bin?

from aerospike-client-go.

I just realized that putting attributes into separate bins allows user to create secondary index on attributes, which is indeed an advantage over putting the entire object in one bin :)

from aerospike-client-go.

It makes sense to provide a marshal/unmarshal interface. I'm waiting for someone to ask for it and validate the use-case.

As to your second question: You can announce which attributes to update using tags:

type User struct {
  Email string // saves attribute as a bin with name `Email` in the database
  Password string `as:"-"` // Transient attribute. Attribute won't be saved in the database.
  PasswordHash []byte `as:"hash"` // This attribute will be saved as a bin with the name `hash`
}

You can have a look at client_object_test.go for all supported cases.

from aerospike-client-go.

Thanks for the explanation.
When I say "change individual attribute", I mean to update PasswordHash but not Email.

This is more or less like a ORM layer, which is useful to many users.
But I'd still highly recommend to put it into a separate package. I think it's better to only put core aerospike db features in the Client object. (Core features are explained in general aerospike doc and can be found in other language's client library).

from aerospike-client-go.