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

Embedded struct support not backward compat with time.Time #25

Closed
prenagha opened this issue Nov 19, 2013 · 4 comments
Closed

Embedded struct support not backward compat with time.Time #25

prenagha opened this issue Nov 19, 2013 · 4 comments

Comments

@prenagha
Copy link

I use the MySql driver from go-sql-driver with the parseTime option. This lets me define fields in structs as time.Time and the driver gets the data loaded properly. Example struct:

type Session struct {
    Id     string
    UserId uint64
    Expire time.Time
}

I have been using sqlx for a few months with no trouble. I recently updated to the latest version of sqlx that has the embedded struct support and now this type of setup no longer works. I suspect it is because time.Time implements scanner and causes sqlx to think it is an embedded struct (which of course it is). In the end I get an error like "Could not find name expire in interface"

Trying to figure out how to properly model this and get it working in conjunction with my mysql driver. Any help would be appreciated.

@jmoiron
Copy link
Owner

jmoiron commented Nov 19, 2013

I think I might just special case time.Time as iirc the lib/pq driver also allows scanning into one.

@prenagha
Copy link
Author

Thanks. Let me know if you need help testing.

@cmillward
Copy link
Contributor

I think I'm still seeing this in the newest code. I can submit a pull request which illustrates the case. Adding another field to the Person model causes failure if it's time.Time but succeeds if you make it use strings (at least using pq). Would that be helpful?

@jmoiron
Copy link
Owner

jmoiron commented Nov 26, 2013

This is a duplicate of #29 which has an associated PR, so I'm closing this in favor of that.

@jmoiron jmoiron closed this as completed Nov 26, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants