Reputation: 13
I was taking a look at how hierarchical data works in Cloud Firestore, and was wondering how that would best translate into a Go struct.
In the linked example, there is a collection of chat rooms, and each chat room document has two fields: a name and a collection of messages.
Would the following be a good way of representing a chat room using a go struct, given that there will be fairly frequent writes to and reads from the messages collection? I would also want to access the messages in the collection in the Go code.
type ChatRoom struct {
Name string
Messages *firestore.CollectionRef
}
This definition seems to compile and works fine, but I was wondering if there are better or more idiomatic ways of going about this.
Upvotes: 1
Views: 93
Reputation: 1042
The documents don't mention a CollectionRef being supported in a document. So I am not sure if that will work. You can see what I am referring to here.
On the other hand I don't think you really gain anything from it since you can access the collection by doing the following.
client.Collection("chatroom/" + <NAME> + "/messages")
Also I don't think it is good practice to entangle a high level type like ChatRoom to a firestore implementation. So I would remove it and create an interface that hides the details of how ChatRooms and Messages are stored. You can do something like this.
type Repo interface {
GetChatRoom(name string) (ChatRoom, error)
GetMessages(name string) ([]Messages, error)
}
Upvotes: 1