[#BATCH-371] FlatFileItemWriter no longer uses LineAggregator

Spring Batch

FlatFileItemWriter no longer uses LineAggregator

Created: 19/Feb/08 12:44 PM Updated: 07/Aug/08 10:06 AM

Component/s:

Infrastructure

Affects Version/s:

1.0.0.m4

Fix Version/s:

1.0.0.m5

Time Tracking:

Not Specified

File Attachments:

DelimitedLineAggregator.patch (1 kB)
2.

FixedLengthLineAggregator.patch (2 kB)
3.

FlatFileItemWriter.patch (4 kB)
4.

LineAggregator.patch (0.9 kB)

Description

« Hide

It seems that the FlatFileItemWriter no longer takes a LineAggregator to determine how lines should be written. This seems to be an oversight?

It could be argued that the ItemTransformer that's injectable could be used instead, except that it only gets invoked when the item type is not String. Additionally, it is asymmetrical with the ItemReader's LineTokenizer. Also, there is no packaged ItemTransformer equivalent to the LineAggregators.

Anyway, as of the moment, it seems the LineAggregators are not used or injectable anywhere, so they should either be made injectable and invoked appropriately again, OR equivalent ItemTransformers should be provided and the LineTokenizers should also be replaced, and the transformer should be invoked even if the item is a String...

All

Comments

Work Log

Change History

FishEye

Builds

Sort Order:

[ Permlink | « Hide ]

Dave Syer added a comment - 19/Feb/08 02:57 PM

I think LineAggregator was overlooked when ItemProcessor/Writer was refactored. I can see there might be some value there, but I can't see where a LineAggregator is going to get a String[] from. If the item is on type String[] (not very likely) it sort of works like a transformer. How did it ever make sense?

[ Permlink | « Hide ]

Dave Syer added a comment - 19/Feb/08 03:41 PM

I moved the existing default transformer out to a top level class, and introduced lineAggregatorItemTransformer as an option. I still don't see a good way to get a String[] in to it reliably.

[ Permlink | « Hide ]

Douglas C. Kaminsky added a comment - 19/Feb/08 06:00 PM

I think the idea would be that the transformer would define how to transform the object into a field set (i.e. a string array) and the aggregator would determine how to write each field in the field set, so each one would serve a distinct purpose in the process of writing.

Why aren't we using the FIeldSet paradigm here again? I like the idea of symmetry between reader and writer.

[ Permlink | « Hide ]

Douglas C. Kaminsky added a comment - 19/Feb/08 06:51 PM

Here's how I see the line aggregators working...

[ Permlink | « Hide ]

Douglas C. Kaminsky added a comment - 19/Feb/08 06:52 PM

And how I see the item writer...

[ Permlink | « Hide ]

Dave Syer added a comment - 20/Feb/08 02:57 AM

I took the inspiration from your patches, and changed the interface of LineAggregator for symmetry with LineTokenizer. The FFIW still has an injected ItemTransformer, but that could be one that uses a LineAggregator. I might change that to be more like your patches if I get time later this week.

[ Permlink | « Hide ]

Dave Syer added a comment - 25/Feb/08 09:00 AM

Now the FFIW has a LineAggregator and a FieldSetUnmapper - so completely symmetric with the ItemReader.

[ Permlink | « Hide ]

Douglas C. Kaminsky added a comment - 25/Feb/08 09:36 AM

Great fix! One thing though, I'm not sure that "Unmapper" is a good way to name it - it's still a mapper, just in the reverse direction. Maybe the Mapper should be called InputFieldSetMapper and this one OutputFieldSetMapper... or Reader/WriterFieldSetMapper...

Unmapper doesn't sit well. Thanks!

[ Permlink | « Hide ]

Dave Syer added a comment - 07/Aug/08 10:06 AM

Assume closed as resolved and released