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

SelectAll support #37

Open
ferhatelmas opened this issue Jun 3, 2015 · 2 comments
Open

SelectAll support #37

ferhatelmas opened this issue Jun 3, 2015 · 2 comments

Comments

@ferhatelmas
Copy link

Is there a plan to support SelectAll ?

var users []User
err := dbm.SelectAll(&users)

Or how welcome are you for it?

@jmoiron
Copy link
Owner

jmoiron commented Jun 3, 2015

I haven't planned on it. It should be trivial to do with dbm.TableFor(User{}).TableName and some simple sql. I think I'd have to wait and see for the patch, because this is slightly tricky and it's fairly easy to just write the query. The advantage of SelectAll would be that you could do it with an unknown type.

I don't think it's necessary to provide a function for any old SQL that you could produce easily. Maintaining a smaller API has its own benefits. CRUD is repetitive and in some cases easy to get wrong, so those kinds of helpers are okay. I am open to arguments in favor, though.

ferhatelmas added a commit to ferhatelmas/modl that referenced this issue Jun 4, 2015
 - fixed user and sslmode params in pg DSN of test runner
@ferhatelmas
Copy link
Author

I agree with you. However, we have a kind of policy not to have any SQL in code. We're reading queries into one holder in setup and use it. Then, it becomes a bit repetitive even for a simple query. Please give a look and let me know if it's good. Thank you!

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

2 participants