Add ETD CSV parser #1556
Add ETD CSV parser #1556
Conversation
Extensible parser using a plugin Update trade parser to use plugin and parse security trades
Add `isKnownFormat()` method
| */ | ||
| public static int parseInteger(String str) { | ||
| return Integer.parseInt(str); | ||
| } |
brianweller89
Sep 14, 2017
Contributor
Is this method adding any value? Calling Integer.parseInt() directly seems good enough
Is this method adding any value? Calling Integer.parseInt() directly seems good enough
jodastephen
Sep 15, 2017
Author
Member
I'm assuming that we may add additional error handling or format handling later. With doubles in other projects we have supported (20) to mean -20.
I'm assuming that we may add additional error handling or format handling later. With doubles in other projects we have supported (20) to mean -20.
brianweller89
Sep 15, 2017
Contributor
ok fair enough
ok fair enough
| * <p> | ||
| * The following standard columns are supported:<br /> | ||
| * <ul> | ||
| * <li>The 'Strata Position Type' column is option, and defines the instrument type, |
brianweller89
Sep 14, 2017
Contributor
optional
optional
| * If that column is not found, the 'Long Quantity' and 'Short Quantity' columns will be used instead. | ||
| * <p> | ||
| * The single 'Expiry' column will normally just be set. | ||
| * Flex futures will also set the 'Expiry Day', 'Settlement Type' and 'Exercise Style'. |
brianweller89
Sep 14, 2017
Contributor
Should this comment reference options rather than futures?
Should this comment reference options rather than futures?
| ValueWithFailures<List<T>> result = ValueWithFailures.of(ImmutableList.of()); | ||
| for (CharSource charSource : charSources) { | ||
| ValueWithFailures<List<T>> singleResult = parseFile(charSource, positionType); | ||
| result = result.combinedWith(singleResult, Guavate::concatToList); |
brianweller89
Sep 14, 2017
Contributor
Static import concatToList() for readibility
Static import concatToList() for readibility
jodastephen
Sep 15, 2017
Author
Member
Its a method reference 😄
Its a method reference
brianweller89
Sep 15, 2017
Contributor
Oops, sorry
Oops, sorry
| // handle longQuantity and shortQuantity | ||
| double longQuantity = parseQuantity(row, LONG_QUANTITY_FIELD); | ||
| double shortQuantity = parseQuantity(row, SHORT_QUANTITY_FIELD); | ||
| double quantity = longQuantity - shortQuantity; |
brianweller89
Sep 14, 2017
Contributor
Probably best to throw an exception or create a failure if quantity, short quantity and long quantity are all not populated.
Silently setting quantity to 0 feels dangerous; it's reasonable to expect clients to always provide a quantity (can always be manually set to 0 in the input if needed)
Probably best to throw an exception or create a failure if quantity, short quantity and long quantity are all not populated.
Silently setting quantity to 0 feels dangerous; it's reasonable to expect clients to always provide a quantity (can always be manually set to 0 in the input if needed)
| private static EtdSettlementType parseEtdSettlementType(String str) { | ||
| String upper = str.toUpperCase(Locale.ENGLISH); | ||
| Map<String, EtdSettlementType> valuesByCode = | ||
| Stream.of(EtdSettlementType.values()).collect(toImmutableMap(EtdSettlementType::getCode)); |
brianweller89
Sep 14, 2017
Contributor
Could store a static version of this map rather than recreating it every time the method is called.
Could store a static version of this map rather than recreating it every time the method is called.
| * @param builder the builder to update | ||
| */ | ||
| public default void parsePositionAttributes(CsvRow row, PositionInfoBuilder builder) { | ||
| // do nothing |
brianweller89
Sep 14, 2017
Contributor
Given that these are builder mutating methods, 'populate' might be a better name than 'parse'.
Are we assuming that overrides of these methods may set non-attribute values on the builder (e.g. settlement date, trade date)?
If yes then parseInfo would be a better name than parseAttributes
If the methods are only expected to populate attributes then we could return a map of attributes and allow the clients to populate the builder
Given that these are builder mutating methods, 'populate' might be a better name than 'parse'.
Are we assuming that overrides of these methods may set non-attribute values on the builder (e.g. settlement date, trade date)?
If yes then parseInfo would be a better name than parseAttributes
If the methods are only expected to populate attributes then we could return a map of attributes and allow the clients to populate the builder
| public void test_parseInteger() { | ||
| assertEquals(LoaderUtils.parseInteger("2"), 2); | ||
| assertThrowsIllegalArg(() -> LoaderUtils.parseInteger("Rubbish")); | ||
| } |
brianweller89
Sep 14, 2017
Contributor
This is just a test of core java functionality
This is just a test of core java functionality
Add
PositionCsvLoaderto complementTradeCsvLoader.Update trade loader to parse security trades.
Add extensibility to parser using a plugin, to pickup attributes.