4 ms·
I'll open an issue in Github about this, but you shouldn't own the entire struct tag, and there is a convention for this. If I want to serialize the same object
by jspthrowaway2 14y ago
I'll open an issue in Github about this, but you shouldn't own the entire struct tag, and there is a convention for this. If I want to serialize the same object to JSON, I should be able to (I can with the way it works right now, but I cannot customize the JSON encoding at all).
Follow convention:
type Foo struct {
Thing string `json:"thinger,omitempty" hood:"pk"`
}
Or, even, get bold and claim sql:
type Foo struct {
Thing string `json:"thinger,omitempty" sql:"size(128)"`
}
You can then use stuff built in to reflect to get the information for you, rather than parsing yourself:
http://golang.org/pkg/reflect/#StructTag http://golang.org/pkg/reflect/#StructTag
That aside, great work! I've been waiting for something like this.
(Edit: Someone already beat me to it: https://github.com/eaigner/hood/issues/1 https://github.com/eaigner/hood/issues/1 -- Hacker Newsers think alike, I guess...)
- eaigner 14y agoThat's a valid issue, definitely want to conform with Go standards and don't break anything. Like the "sql:" proposal very much, will change it to that!
- jspthrowaway2 14y agoI thought about it after commenting and was trying to think of a loose vocabulary you could introduce for "sql" to be interoperable among as-yet unwritten libraries, as jedsmith says on Github, and that's a pretty tough nut to crack. Letting it evolve over time is probably the right choice, so will be interesting to see how your choices impact the SQL landscape down the road.