Re^2: DBI::CSV using a variable to request columns

I think we had this discussion already...

> against column additions, subtractions, and changes

I wonder how is this relevant if one uses ->fetchrow_hashref ?

(like the OP does)

update

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)

Je suis Charlie!}

Comment on Re^2: DBI::CSV using a variable to request columns Download Code

Replies are listed 'Best First'.
Re^3: DBI::CSV using a variable to request columns by chacham (Prior) on May 23, 2016 at 13:26 UTC
I think we had this discussion already... I do not see how that changes the advice. There are ways to avoid some of the errors (disregarding if that is good practice), but the self-documenting part is still true. I wonder how is this relevant It isn't. Hence the introductory, "As an aside".	[reply]
Re^4: DBI::CSV using a variable to request columns by LanX (Saint) on May 23, 2016 at 13:44 UTC
> There are ways to avoid some of the errors (disregarding if that is good practice), but the self-documenting part is still true. Very generic ... In this sense: DRY is also a good practice! :) And less generic: The best practice would be a programming style/ SQL abstraction which allows defining the fields just once and automatically checks a table's integrity at compile-time. Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply]
Re^5: DBI::CSV using a variable to request columns by chacham (Prior) on May 23, 2016 at 16:20 UTC
DRY is also a good practice! So many different people ask, so i spread the idea each time. I fear linking to a writeup would be ignored, and using the same terminology each time would get boring. It even get's boring here (at the office) when i see people making the same stupid mistakes over and over again. I could wish for variety, at least. :) he best practice would be a programming style/ SQL abstraction which allows defining the fields just once and automatically checks a table's integrity at compile-time. If not for perl being the lazy coder's language, i would strongly disagree with that statement, demanding that the coder know what he is dealing with before touching it.	[reply]