Where did ItemProcessor go?!

[davidkarlsen]

Hi!

http://static.springframework.org/sp...x.html#d0e2379

When using a DrivingQuery, there should be
ItemReader: the driving query
ItemProcessor: fetching the full entity from db
ItemWriter: write somewhere else.

i cannot see any options for setting an ItemProcessor on org.springframework.batch.core.step.item.SimpleSte pFactoryBean ??

[davidkarlsen]

It doesn't really need a "pipe" functionality, it's a simple composite pattern:

public class CompositeItemReader implements ItemReader{

  //this is your driving query reader
  private ItemReader delegate;
  //this is the existing dao to pull back the whole object
  private Dao dao;

  public Object read() throws Exception{
    return dao.getItemFromKey( delegate.read() );
  }

  //setters and mark/reset ommitted for clarity
}

I just typed this up quickly, but I think it gives the general idea. You would also want to make sure to register the delegate reader as a stream (or write a passthrough)

Sure - thats what I do - but I'd expect something like this to be available out of the box, as it such a common usecase (even described in the reference guide).

Essentially a combination of ItemReaderAdapter (reuse existing dao) + driving query.

[lucasward]

It doesn't really need a "pipe" functionality, it's a simple composite pattern:

public class CompositeItemReader implements ItemReader{

  //this is your driving query reader
  private ItemReader delegate;
  //this is the existing dao to pull back the whole object
  private Dao dao;

  public Object read() throws Exception{
    return dao.getItemFromKey( delegate.read() );
  }

  //setters and mark/reset ommitted for clarity
}

I just typed this up quickly, but I think it gives the general idea. You would also want to make sure to register the delegate reader as a stream (or write a passthrough)

[davidkarlsen]

You'll have to pull the row back from a dao somewhere in the process, the driving query reader only provides you the primary key. The real question is, do you do it by wrapping the reader, so that the writer gets the full item, or do you treat the primary key as the 'item', and pull back the full row in the writer? I've seen it go both ways at clients, and there isn't really a right answer. However, in 2.0, I would generally say the ItemProcessor is the more appropriate place.

It's also worth noting that the DrivingQueryItemReader has been deprecated in 2.0, and will be replaced with the paging item readers.

I'd like to do it in the reader - as the full object is needed and better to send around (more versatile).

I have an existing dao that could be reused to take in the primary key and return the full object. The ItemReaderAdapter seems ideal for this (e.g. it could call a method to return the full object (targetObject=myDao, targetMethod=getFullObject( int primaryKey ).
However - it's not possible to set any delegate ItemReader on it.

So how can I call an existing dao, fed with a key per step from a driving query - in the itemReader? Seems like the framework is missing a "pipe" functionality for readers - like a transformer with a ReaderDelegate which itself implements ItemReader.

[lucasward]

You'll have to pull the row back from a dao somewhere in the process, the driving query reader only provides you the primary key. The real question is, do you do it by wrapping the reader, so that the writer gets the full item, or do you treat the primary key as the 'item', and pull back the full row in the writer? I've seen it go both ways at clients, and there isn't really a right answer. However, in 2.0, I would generally say the ItemProcessor is the more appropriate place.

It's also worth noting that the DrivingQueryItemReader has been deprecated in 2.0, and will be replaced with the paging item readers.

[davidkarlsen]

Sorry, that's just a mistake in the diagram in the docs. It's really just a composite pattern, wherein you have an ItemReader that contains another ItemReader. The latter could be the driving query reader, while the former could contain the DAO that pulls back more information based on the key.

Sorry - still not convinced.

If I set the ItemReader to a DrivingQueryItemReader.
And the DrivingQueryItemReader has a KeyCollector to fetch the keys, it's still not explained how to get the full object for each iteration (key).

DrivingQueryItemReader's read() implementation only returns the next key, not the full row - so again, how can the full row be fetched???

[lucasward]

Sorry, that's just a mistake in the diagram in the docs. It's really just a composite pattern, wherein you have an ItemReader that contains another ItemReader. The latter could be the driving query reader, while the former could contain the DAO that pulls back more information based on the key.

[davidkarlsen]

It was renamed to ItemTransformer before the final release of 1.0 went out:

http://static.springframework.org/sp...ingle/#d0e2666

However, it's been changed back to ItemProcessor in 2.0

OK - then I do not understand this picture in the documentation for 1.1.3:
http://static.springframework.org/sp...ngQueryJob.png

It refers to a ItemProcessor - and a DrivingQueryItemSource.

How do I initialize my job with the keys from a DrivingQueryItemSource - and add an ItemReader (that fetches the full object/row(s))?

[lucasward]

It was renamed to ItemTransformer before the final release of 1.0 went out:

http://static.springframework.org/sp...ingle/#d0e2666

However, it's been changed back to ItemProcessor in 2.0