Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unmarshal from collection to struct #9

Closed
smartrevolution opened this issue Jun 29, 2013 · 4 comments
Closed

Unmarshal from collection to struct #9

smartrevolution opened this issue Jun 29, 2013 · 4 comments
Assignees

Comments

@smartrevolution
Copy link
Collaborator

If you change the signature of the Read-Method, then it would be easier to directly unmarshal into go-structs. Now, Read() always returns a Map, because the return value is an interface{}.

Let's take a struct and insert a record:
type Person struct {
Firstname string
Lastname string
}

People := myDB.Use("People")
doc := Person{"Rob", "Pike"}
docID, err := People.Insert(doc)

Currently the signature of Read() is:
func (col *Col) Read(id uint64) (doc interface{}, size int)

and Read() returns this:
res, s := People.Read(docID)
-> map[string]interface {}{"Firstname":"Rob", "Lastname":"Pike"}

If you change the signature of Read() to this (and maybe also returning err):
func (col *Col) Read2(id uint64, doc interface{}) (size int)

then it would automatically unmarshal into the struct we passed into the Read-Method:
s := People.Read(docID, &doc)
-> main.Person{Firstname:"Rob", Lastname:"Pike"}

Correct or did I miss something?! If so, do you want to have a pull request from me? :)

@HouzuoGuo
Copy link
Owner

This sounds like a great idea, definitely it will simplify many embedded usage scenarios! Thank you very much!
I totally agree with the idea and have added you into project collaborators, please feel free to make commits.

@HouzuoGuo
Copy link
Owner

If you have some spare time then please go ahead and add the feature, otherwise I could start working on it next week.

@ghost ghost assigned smartrevolution Jun 30, 2013
@smartrevolution
Copy link
Collaborator Author

Okay, thanks. I can do it.

@smartrevolution
Copy link
Collaborator Author

[Updated] Hmm. I get the feeling, that there should be one internal Read() and one external Read()-method without duplicating code. You need the data size to update the indexes, but I think the user is not really interested in the size that is occupied by the data. The user needs to know, if the Read() was successful. The user could check if the returned document is valid, but I think it would be more go-style, if the method would return err. I will suggest a solution and send you a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants