Generalize findMap to allow instantiation of multi-argument objects

[plandem]

Well, i need to get Map<int, object> from query. i.e. not only 2 value, but much more. But for finMap there is no way to provide another MapResultSetProcessor, like at findAll. But findAll returns List, not Map.

p.s.: what i want as result - map with PK as Key and object self as value (Map<PrimaryKey, Model>)

[komu]

I've been considering generalizing findMap so that first result column is used to instantiate the first argument and all of the rest are used to instantiate the second argument (instead of using just the second column.)

This would mean you could say:

class SalaryStatistics {
    BigDecimal min;
    BigDecimal max;
    BigDecimal average;
}

...

Map<Integer,SalaryStatistics> salariesByDepartmentId =
    db.findMap(Integer.class, SalaryStatistics.class, 
        "select id, min(salary) as min, max(salary) as max, avg(salary) as average" +
        " from deparment group by id");

Would this answer your needs?

[plandem]

yes. that's exactly what i want to get as result - first column (in my case PK and as result map will be indexed by PK) and as second - whole class.

[plandem]

it's not a problem if final models will not have 'id' - it's much less troubles, finally i have a indexed map where i can get 'id'.

[komu]

Right, I'll implement this at some point. I've needed it myself as well sometimes.

Actually, you can have id in the model as well, because you can include it twice in the result list. You could say something like:

db.findMap(Integer.class, MyModel.class, 
    "select id as key, id, name, data from my_table");

By the way, are you using Java 8? If you are, it's relatively easy to build a map from list as well. You can just say:

List<Foo> foos = ...
List<Integer,Foo> foosById = 
    foos.stream().collect(Collectors.toMap(Foo::getId, Function.identity()));

So there's actually not that much to benefit from having Dalesbred implement this directly. (This is the reason why I haven't yet implemented this.)

[plandem]

right now i'm using java8, but i'm sure that i will not have to back to java7 (at some point, client can request for outdated java7 due to his own java stack) :( but thanks for help, right for now - it will help :)

[komu]

Right. The upcoming Dalesbred 1.0 will only support Java 8 (even Oracle has stopped support for Java 7 and I get to use Optional<T> and lambdas to make some public interfaces clearer), but I could possibly backport this to 0.8 -branch if necessary. Or at least I will accept pull request if someone else backports my code to older branch once it's completed.