3 ms·

The populating objects part doesn't seem to be the hardest part. The impedance mismatch with ORM is trying to merge the concepts of "result sets" that are not

The populating objects part doesn't seem to be the hardest part. The impedance mismatch with ORM is trying to merge the concepts of "result sets" that are not "table rows" to objects in such a way that you can interact with them on a per-table row basis. It's easy to say that each row in the users table represents a user so each row is a distinct object. It's harder when you want to get data out of the database using a single query that hits multiple tables and returns a joined result set that doesn't map to the already established object hierarchy, an object hierarchy that is based on the normalized schema. Denormalizing only helps with some parts of this. Writing the naive ORM implementation that tries to model a relational schema as a sets of nested objects is doable, but it becomes difficult to get decent performance out of it, since the kinds of queries that map rows to objects are not usually the kinds of queries that are performant in SQL.

ilyak 17y ago
Populating objects isn't the hardest part, but it's the most useful part. Writing object populating code is tedious, copy-pasty and uncool. And having that, you don't really need ORM, naive or not.
- bokonist 17y ago
  If you're in Java, just use BeanResultHandler. We use helper functions that simply wrap the low level queries using beanhandler. So all my queries end up looking like: List<MyObject> myobjects = dbUtils.select("SELECT name,age FROM (some complex query ... )", params, MyObject.class) BeanHandler will automatically fill any property in MyObject with a column of a matching name from the select statement.
  - ilyak 17y ago
    This is not enough: you should also set up references to other objects (by id) and deal with underscore_database_names vs camelCaseJavaNames.
    - randallsquared 17y ago
      ...via setting. But that last is trivial. Just add it.
    - thwarted 17y ago
      And include a singular<->plural mapping for column and table names.

ilyak 17y ago

Populating objects isn't the hardest part, but it's the most useful part. Writing object populating code is tedious, copy-pasty and uncool. And having that, you don't really need ORM, naive or not.

bokonist 17y ago
If you're in Java, just use BeanResultHandler. We use helper functions that simply wrap the low level queries using beanhandler. So all my queries end up looking like: List<MyObject> myobjects = dbUtils.select("SELECT name,age FROM (some complex query ... )", params, MyObject.class) BeanHandler will automatically fill any property in MyObject with a column of a matching name from the select statement.
- ilyak 17y ago
  This is not enough: you should also set up references to other objects (by id) and deal with underscore_database_names vs camelCaseJavaNames.
  - randallsquared 17y ago
    ...via setting. But that last is trivial. Just add it.
  - thwarted 17y ago
    And include a singular<->plural mapping for column and table names.