Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add the ability to write CSV files. #42
I would like to second this. Currently I use CSVeed in my project and also have the an old 2.4-SNAPSHOT version of OpenCSV just for bean writing. Would like to switch entirely to CSVeed. The main class I use in the no longer updated OpenCSV is BeanToCsv which should be relatively easy to adapt to the CSVeed framework. Here is that class. fyi, the dateformat conversion was not in the original code, I added that. The opencsv license is the same apache 2.0 license as csveed.
v0.4.0 has been released, containing basic write functionality. There are a couple of things that are handy to have, like dynamic column support, the ability to declare whether quotes are required for cells, the ability to declare a custom order etc.
Perhaps you can have a look and let me know what you think of the write-ability of CSVeed?
Sorry for late reply. The opportunity only now came up to revisit the CSV writing part of the code. I spent today trying to integrate the new version, with only partial success.
I'm getting a NullPointerException in the constructor of HeaderImpl.
I suspect the issue is that the loop for
is iterating through every property picked up by introspection, and ignoring the fact that properties may have been manually mapped. For reading purposes, I generate I create my BeanInstructions (formerly BeanReaderInstructions) as follows:
TolerantColumnNameMapper is a ColumnNameMapper that tolaterates missing column names when reading. If I have an old zip file and I've added a field to a Bean, it just gives a warning when the zip file is missing something as opposed to throwing an exception and terminating out of the entire reading process:
I'm not familiar enough with the framework to fix how the header loop and possibly other write loops should work. So until this is fixed, I'll have to stick with the old csv writing code.
On a slightly separate note, I noticed you made
a required part of the Converter interface. No issues with that except you should probably provide a default implementation in AbstractConverter since it will usually be value.toString() anyway. So for now, I'm using EasierAbstractConverter as follows instead of AbstractConverter: