search

quux00 / simplecsv

CSV parser for Java, based on the OpenCSV model, but fixing many of the inconsistencies and defects of that codebase.
Other
11 stars 3 forks source link

New bean->CSV strategy: autodetect fields #9

Open kryger opened 10 years ago

kryger commented 10 years ago

All (both?) mapping strategies (ColumnPositionMappingStrategy and HeaderColumnNameTranslateMappingStrategy) require pre-configuration with column names or mappings, I've been looking for a CSV writer that would simply serialize any object that's thrown at it (in a manner similar to Jackson's JSON serialization). Would it be feasible to create a strategy that reflectively detects all serializable fields of an arbitrary object and writes everything, not worrying too much about the order? The point is to get away with as little configuration as necessary, my plan was to use the CSV writer in a Spring MVC environment where requesting different content type would return different representation of the resource transparently, using Spring converters. Having to specify input object type and column names is not feasible in this scenario. Happy to make a stab at it if you think this wouldn't be too big of a job. There could also be other considerations I haven't thought of (is it even possible to represent an object in CSV reliably? If not, is it OK to silently return truncated representation? etc., etc.).

quux00 commented 10 years ago

Interesting - I was just saying I didn't want simplecsv to become the Jackson of CSV parsers in the last issue before I read this one :-)

My view of simplecsv is that the core must remain simple, obvious and fast. Which means no reflection and someone can read the code and understand it in 10 minutes or less. By "core" I mean stuff in the net.quux00.simplecsv package.

I'm not opposed to adding embellishments to the other features in other packages, but I don't want to make maintaining this library a huge time sink.

So my first suggestion would - can SuperCSV do that? If not (or you don't like SuperCSV), then we can consider adding it here, but it would need to be fairly straightforward code. I'm not a big fan of Reflection, but done with simplicity as the primary goal Reflection can be done in a way that is comprehensible to a maintainer. If done with feature creep in mind (I'm looking at you Jackson), the codebase is a monster - so complicated you can't follow what's happening even with a debugger. I don't want to maintain a monstrosity. Too many other programming projects to do!

kryger commented 10 years ago

Yep, agreed on Jackson's complexity (it's awesome as long as you don't have to look under the hood) and I see your point regarding long-term maintenance. I briefly considered SuperCSV but it still seems to require a lot of configuration (and it's on SourceForge...), I may re-evaluate it again though; I'm in an early phase of a project but CSV reporting is on the bottom on the priority list so I may not end up with enough time to spend as much time on that aspect as I'd like to.

Thanks for quick reply and honest input :). I'll come back to this when I'm closer to actually dealing with CSV, I hope the related issues can remain open for some time?