Eonblast/Emysql — pull request #100 by choptastic (2013-09-18 16:50:57+00:00)
Title: emysql_util:affected_rows/1, insert_id/1, result_type/1 some updates to emysql_util for consistency, and some readme fixes

Hello folks,

I've got a handful of changes here, mostly modifications to emysql_util, specifically for the purpose of minimizing the necessity of requiring the user to include the emysql.hrl file in their modules.

The three newly introduced functions are as follows:

* `emysql_util:insert_id/1` -> returns `insert_id` from an `#ok_packet{}`
* `emysql_util:affected_rows/1` -> returns `affected_rows` from an `#ok_packet{}`
* `emysql_util:result_type/1` -> returns `ok | result | eof | error` depending on the type of `#X_packet` provided it.

I realize that all of these can currently be gotten either by picking the tuples apart, or by including the emysql.hrl file, but both of those methods *feel* wrong, and that the API should treat the results mainly opaquely. Hopefully you agree :)

Beyond that, this pull request includes a few stylistic tweaks to emysql_util:

1) In a handful of places, functions within emysql_util were referencing the module `emysql_util` (e.g. calling `emysql_util:dualmap` instead of just `dualmap()`). Not a gamechanging fix by any stretch, but I figured since *most* of the calls were local, I'd change the rest of them to be local calls as well.
2) emysql_util was an odd mix of spaces and tabs, and since erlang code is *typically* spaces instead of tabs, I converted to spaces.
3) Made consistent any use of `is_record` in emysql_util, which in some places used the record in a match (`Res = #result_packet`), where in others used `is_record(Res, result_packet)`. I just modified it to use the match spec (it was only two or three places, I believe, but it's now consistent throughout the module)
4) Simplified emysql_util:field_names
5) A conversion from `array:to_list(array:new([erlang:length(FieldNames)]))` (which frankly feels odd to me), to `lists:duplicate(length(FieldNames), undefined)`, which feels more straightforward, and upon my initial benchmarks seemed to be about the same with performance, and if at all, marginally faster.
6) Finally, I noticed that in the list of contributor's names at the bottom, those that were email addresses were being treated by github as local URLs, (e.g. `http://some/path/my@email.com`), so I just tacked a `mailto:` to the front.

Feel free to reject any part of this, or if you'd prefer me to convert it into several PRs instead of just one, or to rebase it into a single mishmash commit - though each commit in this PR does compile and accomplishes mostly one distinct task).

Anywho, thanks for all you do here, and let me know your thoughts.