[#BATCH-730] HibernateCursorItemReader Parameters

Spring Batch

BATCH-282

HibernateCursorItemReader Parameters

Created: 16/Jul/08 08:04 PM Updated: 23/Sep/08 02:08 PM

Component/s:

Core

Affects Version/s:

1.1.0

Fix Version/s:

2.0.0.M3

Time Tracking:

Original Estimate:

0.06d

Remaining Estimate:

0.06d

Time Spent:

Not Specified

Description

« Hide

As per this discussion: http://forum.springframework.org/showthread.php?p=191776#post191776

"It would be great if there was a version of HibernateCursorItemReader that was 'parameter aware' out of the box, so you could add parameters to your hql string that the HibernateCursorItemReader would then attempt to fetch from the StepExecutionContext, similar, I suppose, to HibernateTemplate.findByNamedParam."

It was mentioned that the same could work for JdbcCursorItemReader. It could try to find the named param in the execution context, then possibly fall back to a map that could be provided through injection.

All

Comments

Work Log

Change History

FishEye

Related Builds

Sort Order:

[ Permlink | « Hide ]

Dave Syer added a comment - 17/Jul/08 02:21 AM

I don't like the idea of tying input parameters to the ExecutionContext (I would like to see that concern separated entirely from the readers and writers, but that's another story). Input parameters are really JobParameters, and that's a problem because the readers are supposed to be usable without the spring-batch-core.

N.B. in the Jdbc case there is already a parameter-aware PreparedStatementSetter in core (so I removed that part of the issue summary). I don't see why the same approach shouldn't be used for Hibernate.

[ Permlink | « Hide ]

Lucas Ward added a comment - 17/Jul/08 01:33 PM

Dave,

I was a bit late commenting on this issue, but I agree, the same approach that's used in JdbcCursorItemReader should be used. Some extra interface such as SessionParameterSetter should be created, which could have an implementation that pulls them from JobParameters.