search

atais / Fixed-Length

Scala library for parsing fixed length file format
MIT License
13 stars 12 forks source link

Add truncation capability as to not create invalid messages #17

Closed RoccoMathijn closed 2 years ago

RoccoMathijn commented 2 years ago

Hey, I added a capability to truncate fields according to the specified start and end positions

Lmk what you think

RoccoMathijn commented 2 years ago

Rebasing on https://github.com/atais/Fixed-Length/pull/16 will fix the build. Waiting for a review on that

codecov[bot] commented 2 years ago

Codecov Report

Merging #17 (4e1d437) into master (79ee988) will not change coverage. The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##            master       #17   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            7         7           
  Lines           97       100    +3     
=========================================
+ Hits            97       100    +3
Impacted Files Coverage Δ
...ain/scala/com/github/atais/fixedlength/Codec.scala 100.00% <100.00%> (ø)
...n/scala/com/github/atais/fixedlength/Encoder.scala 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 79ee988...4e1d437. Read the comment docs.

atais commented 2 years ago

LGTM.

Overall I see why you need it ;-) But...

On the other hand maybe it would be better to make Encoder returning Try or Either and be able to react on those errors? WDYT?

RoccoMathijn commented 2 years ago

LGTM.

Overall I see why you need it ;-) But...

On the other hand maybe it would be better to make Encoder returning Try or Either and be able to react on those errors? WDYT?

I Like that approach too. However the codecs now are a really nice grammar specification of a fixed length line/file. If we throw an encoding error it would mean we would have to move field truncation to a different place where we need all the information on field lengths again.

In my case, where I'm working on a fixed length file with 140+ fields that would get real messy.

Or did you have something else in mind?

atais commented 2 years ago

Or did you have something else in mind?

That was my idea exactly.

It's hard for me to tell how is this lib actually behaving in long term or what would come useful because I have used it only for a month or two in a project and it was abandoned.

So I am glad to see someone finds it useful and is willing to put some work to make it better! Thanks