commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [CSV][POLL] How to provide mutable records
Date Tue, 22 Aug 2017 20:28:02 GMT


Am 22.08.2017 um 21:34 schrieb Gary Gregory:
> On Tue, Aug 22, 2017 at 1:27 PM, Oliver Heger <oliver.heger@oliver-heger.de>
> wrote:
> 
>>
>>
>> Am 21.08.2017 um 23:29 schrieb sebb:
>>> On 21 August 2017 at 21:04, Gary Gregory <garydgregory@gmail.com> wrote:
>>>> Hi All,
>>>>
>>>> We have a request for [CSV] to provide mutable records. There is no
>> clear
>>>> consensus to me on how to do this. The current CSVRecord class is
>> immutable
>>>> but is not documented as such. I attribute that to YAGNI up to now.
>>>>
>>>> Options range from simply making CSVRecord immutable to creating a new
>>>> CSVMutableRecord class and a few things in between.
>>>>
>>>> I'd like to get a feel what the community thinks here. IMO this boils
>> down
>>>> to whether or not it matters that CSVRecord remains immutable.
>>>>
>>>> [0] do nothing
>>>>
>>>> [1] Add two put methods to CVSRecord making the class mutable:
>>>> put(int,Object) and put(String,Object). This does not break BC but
>> changes
>>>> the runtime behavior for apps that expect immutable record and shard the
>>>> records with other components.
>>>>
>>>> [2] Add a "mutableRecord" boolean option to CVSRecord and CSVFormat such
>>>> that a new boolean in CVSRecord allow method from 1) above to either
>> work
>>>> or throw an exception.
>>>>
>>>> [3] Add a "mutableRecord" boolean option to CVSRecord and CSVFormat such
>>>> that subclass of CVSRecord called CVSMutableRecord is created which
>>>> contains two new put methods. See branch CSV-216.
>>>>
>>>> [4] The factory method:
>>>>  /**
>>>>   * @param orig Original to be copied.
>>>>   * @param replace Fields to be replaced.
>>>>   * @return a copy of "orig", except for the fields in "replace".
>>>>   */
>>>>  public static CSVRecord createRecord(CSVRecord orig,
>>>>                                       Pair<Integer, String> ... replace)
>>>>
>>>> Could also be:
>>>>  public static CSVRecord createRecord(CSVRecord orig,
>>>>                                       int[] replaceIndices,
>>>>                                       String[] replaceValues)
>>>>
>>>> I like the simplicity of [1] and I coded [3] to see how cumbersome that
>>>> feels.
>>>>
>>>> So my preference is [1].
>>>
>>> What about [4]?
>>>
>>> Would that be more complicated/cumbersome to use than [1]?
>>>
>>> Seems to me using a factory or builder to create an updated immutable
>>> copy is the way to go here.
>>
>> Since Java 8 functional concepts and immutable data structures become
>> more and more popular. It feels a bit strange to me going the opposite
>> route. So my preference would also go towards [4].
>>
>> The main use case was ETL, correct? We could check how such an approach
>> would look like in such a scenario and maybe even add more support, e.g.
>> implement a transformation loop that allows configuring a transformation
>> function.
>>
> 
> 
> The use case is, IMO, _lightweight_ ETL; for anything serious I would use
> Spring Batch. This is why I favor the simplest solution.

For this poll my first point is relevant. Regarding lightweight ETL,
maybe the new reactive streams in Java 9 may bring some interesting
concepts for the future?

Oliver
> 
> Gary
> 
> 
>>
>> Oliver
>>
>>>
>>>> Gary
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message