Add row mappers.

[jasperblues]

• Add a row mapper and result set extract protocol that allow functional transformation of the result set to the domain model type.

These methods simplify the implementation of a DAO (data access object):

• Reduces boiler plate code
• Multiple methods listByFoo, listByBar, findById, etc can use the common mapping method.

Analogous to Spring JDBC RowMapper and ResultSetExtractor:

• http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jdbc/core/RowMapper.html
• http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/jdbc/core/RowMapperResultSetExtractor.html

[ccgus]

Thanks for doing this- I'll have to take a closer look at this and see if it's something that'll fit in FMDB or not. I'm trying to keep it super slim as possible these days, though I really should have some sort of "neat stuff to have" folder of add-ons.

[jasperblues]

You're welcome. For me this small addition addresses something that is something missing. But its up to you whether its appropriate for the fmdb core (I understand your concerns). If not, I'll create a separate pod outside the project and add it in that way. In fact this would be an interesting experiment to see how many people star it, as an indication of general utility. . . . . or, as you say, it could be an add-on sub-spec.

[azplanlos]

Maybe you also want to have a look on SISQLiteContext - a class extending FMDB by CoreData like convenience functions. Tried to keep it lightweight and suitable for big data sources and still you can access the core db underneath by utilizing FMDB.

[jasperblues]

@azplanlos Thanks, will take a look! But this particular change is just a very small change - a handful of lines of code to map a result set to a model object. When implementing a Data Access Object (DAO) we'd want this for findBy, listBy, etc methods. We could simply define a method to do this, but it adds some structure - functional style mapping.