That looks odd to me. What comes up for me is the use case where I want to
ETL a file of 10,000,000 records and update, say, one column. If am forced
to create a brand new record for every record read, that would be a shame.
If I had a mutable record, I could just keep on updating it and using it to
write each row. Read record, update it, write record. No extra memory
needed.
Either we can make the current record mutable (what's the harm?) or we can
make the parser serve out mutable records based on a config setting. This
could be a subclass of CSVRecord with the extra method I proposed.
Thoughts?
Gary
On Tue, Aug 15, 2017 at 8:33 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
> On Tue, 15 Aug 2017 08:01:53 -0600, Gary Gregory wrote:
>
>> How does that work when you want to change more than one value?
>>
>
> How about a "vararg" argument:
>
> /**
> * @param orig Original to be copied.
> * @param replace Fields to be replaced.
> */
> public static CSVRecord createRecord(CSVRecord orig,
> Pair<Integer, String> ... replace) {
> // ...
> }
>
>
> Gilles
>
>
>
>> Gary
>>
>> On Aug 15, 2017 00:17, "Benedikt Ritter" <brit...@apache.org> wrote:
>>
>> Hi,
>>>
>>> I very much like that CSVRecord is unmodifiable. So I’d suggest an API,
>>> that creates a new record instead of mutating the existing one:
>>>
>>> CSVRecord newRecord = myRecord.put(1, „value")
>>>
>>> I’m not sure about „put“ as a method name since it clashes with
>>> java.util.Map#put, which is mutation based...
>>>
>>> Regards,
>>> Benedikt
>>>
>>> > Am 15.08.2017 um 02:54 schrieb Gary Gregory <garydgreg...@gmail.com>:
>>> >
>>> > Feel free to provide a PR on GitHub :-)
>>> >
>>> > Gary
>>> >
>>> > On Aug 14, 2017 15:29, "Gary Gregory" <garydgreg...@gmail.com> wrote:
>>> >
>>> >> I think we've kept the design as YAGNI as possible... :-)
>>> >>
>>> >> Gary
>>> >>
>>> >> On Mon, Aug 14, 2017 at 3:25 PM, nitin mahendru <
>>> >> nitin.mahendr...@gmail.com> wrote:
>>> >>
>>> >>> Yeah that also is OK. I though there is a reason to keep the
>>> CSVRecord
>>> >>> without setters. But maybe not!
>>> >>>
>>> >>> Nitin
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Mon, Aug 14, 2017 at 2:22 PM Gary Gregory <garydgreg...@gmail.com
>>> >
>>> >>> wrote:
>>> >>>
>>> >>>> Hi All:
>>> >>>>
>>> >>>> Should we consider adding put(int,Object) and put(String, Object) to
>>> the
>>> >>>> current CSVRecord class?
>>> >>>>
>>> >>>> Gary
>>> >>>>
>>> >>>> On Mon, Aug 14, 2017 at 2:54 PM, nitin mahendru <
>>> >>>> nitin.mahendr...@gmail.com>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> Hi Everyone,
>>> >>>>>
>>> >>>>> I recently pushed a change(pull request 20) to get the line ending
>>> >>> from
>>> >>>> the
>>> >>>>> parser.
>>> >>>>>
>>> >>>>> Now I want to push another change which I feel will also be useful
>>> for
>>> >>>> the
>>> >>>>> community. I want to add a CSVRecordMutable class which had a
>>> >>> constructor
>>> >>>>> which accepts a CSVRecord object. So when we have a
>>> CSVRecordMutable
>>> >>>> object
>>> >>>>> from it then we can edit individual columns using it.
>>> >>>>>
>>> >>>>> I would be using this to write back my edited CSV file. My use case
>>> >>> is to
>>> >>>>> read a csv, mangle some columns, write back a new csv.
>>> >>>>>
>>> >>>>> I could have directly raised a pull request but I just wanted to
>>> float
>>> >>>> the
>>> >>>>> idea before and see the reaction.
>>> >>>>>
>>> >>>>> Thanks
>>> >>>>>
>>> >>>>> Nitin
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>
>>> >>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>
