<p>We stamped 1.0.0 on our new ORM generator. It's based on code generation
and it uses a database-first approach. We're really exicted to show it to the
community and get some feedback. See the readme for details, getting started,
benchmarks and more.</p>
<p><a href="https://github.com/vattle/sqlboiler">https://github.com/vattle/sqlboiler</a></p>
<hr/>**评论：**<br/><br/>bear1728: <pre><p>I know there is a lot of ORMs around, but this one looks really neat! I especially like the idea of making it "db first", compatibility tests, automatic timestamps, and the readme is well done and has a lot of info. Well done! The only thing I would suggest is sqlite support, but I know that takes time and it probably less popular for these things. So I understand going for postgres.</p></pre>aarondl: <pre><p>Yeah, it wasn't one of our goals. But it's not much modification away from being able be used with both mysql/sqlite I believe. If people like it enough, I'm sure someone will do the work. And I'm willing to help guide/and code review to get whatever support in.</p></pre>DylanJ: <pre><p>I am using this in a project and so far it's been pretty great! Simple syntax and it even supports Upsert and Locking!</p></pre>kocekoga: <pre><p>This is awesome, comprehensive, well thought out, has all the features I ever wanted, I was even contemplating to implement something similar my self, so great job!</p>
<p>BUT, now that I have it at the grasp of my hands, I am not sure I want it :D. I started reading through the readme page while processing in my head how this would look like in my project. Thoughts that were coming to me were: "How do I do this?", "Oh that way, that's nice, but how do you handle this case?", "Scroll down scroll up, oh that way, hm but there is this restriction, well for this particular case we can't make an exception, but what if I...". And suddenly I caught my self finding a reason to use the new shiny thing when I already had one which is perfectly flexible, powerful and adequate for all of my uses, the plain sql. It just feels like another layer to learn, another layer to think of when making braking changes, another abstraction that has restrictions which force me to mend my model.</p>
<p>Of course this is just a rant. And I am sorry to shit about it when you put so much effort in it. But here I have collection of all features that I ever wanted and I am still not satisfied. It's how I feel whenever checking out new ORM-ish library looking for a holly grail to solve object relational impedance mismatch.</p>
<p>Anyway it's close to perfect and I see lot's of use cases where it would be extremely effective in use. One nitpick though, since this is a code generation tool, benchmarks should compare it to plain sql executions and other "cleaner" solutions like sqlx, not full blown ORM like gorm.</p></pre>aarondl: <pre><p>Of course I don't mind a rant, or criticism as long as I'm allowed to retort!</p>
<p>There is of course exceptions to where this library will be useful. Even ActiveRecord has it's limitations where you fallback to raw queries to get the intense things done, and of course that's a use case we support. No ORM can cover every use case, the point is (as the name implies) to remove boilerplate from projects. That's to say I don't want to have to create a models folder, and start rewriting all the code that this would generate for you. I don't want to put a bunch of magic SQL strings that aren't checked at compilation time, and send all the whitespace inserted by Go's backticks string literal syntax to postgres. And of course you have to do that unless your project is tiny and you only ever fetch from your users table in one place, otherwise you're violating encapsulation, code re-use and general good coding practices. To me this is the sqlx way you describe as "clean", but I can't help but consider it very dirty and very repetitive, especially if you've just done all that work for one database in a project and then you move on to a new one, time to write SQL again!</p>
<p>So you see it's not that this is necessary, or that it covers all the use cases, it's just that it makes for far less code because very likely I will end up writing all of this code by hand, something to load my users, something to update them, insert them, look up their relationships, count them, etc. You could also compare this to sqlx itself, why do you use it? Because Scan() is boilerplate you can do without. I feel like the basic CRUD operations are boilerplate I can do without.</p>
<p>And of course there is no holy grail, so we should all stop searching if we haven't already ;)</p>
<p>PS. Check the benchmarks, we do benchmark against sqlx to compare our raw binding speed because that's all sqlx does. We beat them. And we compare to the other ORM-like libraries out there because our featureset is much closer to them than to sqlx which has only one real feature: binding to structs. If we tested our inserts against them it wouldn't be fair because we do more work than they do eg. auto timestamps. GORM/GORP/XORM/SQLBoiler all accomplish the exact same task with the same features, the implementation and approach is all that differs which is exactly when you want to be benchmarking, to compare implementations solving the same problem.</p>
<p>Thanks for your comments!</p></pre>Midnightblues: <pre><p>Not sure if I'm doing this wrong, but running the installation command in the README is failing? There doesn't seem to be a cmd directory in the repository?</p>
<p>Project looks great! Looking forward to trying it out.</p></pre>aarondl: <pre><p>Fixed the download command, that was outdated from when we were playing around with vendoring - an experiment that failed :(</p></pre>Midnightblues: <pre><p>Thanks for the update! :)</p></pre>
