Re^2: Text::CSV_XS - proposed new interface

[jZed]

> Where do the column names come from?

Good question! My thought was that if the user specifies a comma-separated columns attribute in the new() flags, those will be the column names and the first row of the file will be treated as data but that if none is supplied, the first row of data will be treated as the column names.

> The old interface really is strange

Yep, though very usable once you get used to it. (I inherited the interface from the module's original author). The odd thing is that in the six years the module has been on CPAN, no one has mentioned this. Bart and Diotalevi griped loudly in the CB, so I listened. Griping++. (polite griping)++++. (sending messages to CPAN authors that they have strange interfaces with examples of what's strange and what might be better)++++++.

[doom]

> Where do the column names come from? Good question! My thought was that if the user specifies a comma-separated columns attribute in the new() flags, those will be the column names and the first row of the file will be treated as data but that if none is supplied, the first row of data will be treated as the column names.

Think about this part very carefully. There are continual problems with DBD::CSV, because the column descriptions that work well in spreadsheets don't map directly to valid SQL column names. "Profit & Loss" works in a spreadsheet, but has to become something like "PROFIT_AND_LOSS" in a database.

By the way, allowing embedded EOLs by default sounds good. It would also be good to allow extended characters by default. The first thing I tell everyone about Text::CSV_XS is that they need to turn "binary" on...

[jZed]

> There are continual problems with DBD::CSV, because the
> column descriptions that work well in spreadsheets don't
> map directly to valid SQL column names.

Text::CSV_XS won't care about valid SQL names, that part is added by DBD::CSV and is easily handled. From the DBD::CSV pod:

"you can supply an array ref of column names with the col_names attribute."

> It would also be good to allow extended characters by
> default.

Yes, that will be the case.