Dave Syer - 04/Feb/08 08:47 AM 1) is fixed. I actually assumed that 2) was intentional. Lucase can verify. 3) I don't really care. 4) the general approach with cursor and driving query ItemReaders is to provide the primary key. Not a resultset with all properies of a domain object. The domain object mapping therefore needs to be done in an ItemWriter.

Douglas C. Kaminsky - 04/Feb/08 09:16 AM I presumed that 4) was relevant since the SingleColumn version seems to allow this... or am I misinterpreting the intention of that field in the SingleColumn version, too?

Dave Syer - 04/Feb/08 09:30 AM I see what you mean, but I think it might just be the names of the properties (and the javadocs in the setter) which are confusing. The KeyGenerator is for generating primary keys - they have to be represented as Java objects, so we need a mapper strategy. The default should suffice for most cases. But the idea is *not* to map to domain objects in the KeyGenerator, as far as I know. Lucas needs to rule on this one (and fix the docs if I am right).

Douglas C. Kaminsky - 04/Feb/08 09:35 AM I definitely understand the intended purpose of the key generators. The mapper in the single column version actually confuses me. It's not used directly in creating restart data like it is in the multiple one, so its purpose isn't clear... one of the JdbcTemplate query methods could be used to force a list of Serializables to be returned instead of using the SingleColumnRowMapper, so it all seems superfluous to me unless you're allowing whole objects to be returned.

Lucas Ward - 10/Mar/08 01:44 PM Doug, The entire point of the KeyMapper in the SingleColumn version is in case someone wants a specific type for their keys other than the simple object. I think that the vast majority of projects will be fine with letting SingleColumnRowMapper return well known objects, but I have seen clients where they used a particular domain object to represent a key, something like SqlIdentityKey for various reasons. It seems to me that it would be better to use well known types, but since I was already using the RowMapper interface to map the keys, I didn't see a reason not to allow a setter for it. In regards to the MultipleColumn version, I think you're confused when looking at what is now the ExecutionContextKeyMapper, which extends RowMapper, thus allowing for the exact same functionality as the single column version (I'm assuming you missed the extends?) This scenario is the primary reason I have seen projects use a separate class to represent a key, they wanted a very specific class to represent their keys so that it could effectively support scenarios where the key is made up of more than one column. I've been reviewing this again as I write the documentation and it still seems to make sense to me, but if you still have some confusion or feel like it might be improved please feel free to respond, otherwise I'll close the issue.

Douglas C. Kaminsky - 10/Mar/08 02:01 PM No problem. I see what you're saying and although it's still a slightly confusing mechanism, documentation can address this. Close 'er up.

Lucas Ward - 10/Mar/08 02:40 PM I added quite a bit of javadocs to the ExecutionContextRowMapper, so hopefully this helps in understanding how it works. If there are any issues with the basic contract, please raise as a new jira issue. The other half, creating documentation for the approach, will be solved as part of BATCH-316