| Key: |
BATCH-140
|
| Type: |
Improvement
|
| Status: |
Closed
|
| Resolution: |
Fixed
|
| Priority: |
Critical
|
| Assignee: |
Lucas Ward
|
| Reporter: |
Lucas Ward
|
| Votes: |
0
|
| Watchers: |
1
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Depends
|
|
|
|
This issue is depended on by:
|
|
BATCH-145
Move CollectionItemProvider to infrastructure from samples
|
|
|
|
 |
BATCH-108
Improve error reporting when parsing input files
|
|
|
|
|
|
|
|
|
|
|
File input and output sources should be refactored in order to create more sensible interfaces that are consistent with other input sources. For example, both the stax and sql input sources returns an object when read() is called. StAX does this by delegating to an OXM framework to map xml, and sql does the same using a passed in RowMapper. However, the FlatFileInputSources returned a FieldSet that then returns an object. It would be more sensible to inject a mapper into the file input sources and return a mapped object. In this way, all of the input sources would be consistent, which would require less stock ItemProviders, and would allow for BATCH-118 to be fixed, since the input source could catch a mapping exception and wrap it in another exception that contained the original line read in.
The same could be done with the FileOutputSource, by injecting an aggregator into it, similar to how the input has a tokenizer injected in.
|
|
Description
|
File input and output sources should be refactored in order to create more sensible interfaces that are consistent with other input sources. For example, both the stax and sql input sources returns an object when read() is called. StAX does this by delegating to an OXM framework to map xml, and sql does the same using a passed in RowMapper. However, the FlatFileInputSources returned a FieldSet that then returns an object. It would be more sensible to inject a mapper into the file input sources and return a mapped object. In this way, all of the input sources would be consistent, which would require less stock ItemProviders, and would allow for BATCH-118 to be fixed, since the input source could catch a mapping exception and wrap it in another exception that contained the original line read in.
The same could be done with the FileOutputSource, by injecting an aggregator into it, similar to how the input has a tokenizer injected in. |
Show » |
|
File Input and Output should be refactored
I guess the answer is to either have a pass-thru mapper and let the item provider deal with it as it does now, or to encourage putting the complex logic inside the mapper. I guess either works, so people can just choose. In the latter case the item provider would get an Object back from the mapper and would have to make a decision then about whether it was a logical record terminator or not.