Am 22.08.2017 um 21:34 schrieb Gary Gregory: > On Tue, Aug 22, 2017 at 1:27 PM, Oliver Heger <oliver.he...@oliver-heger.de> > wrote: > >> >> >> Am 21.08.2017 um 23:29 schrieb sebb: >>> On 21 August 2017 at 21:04, Gary Gregory <garydgreg...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
