My program does not expect any order. That's what "hashes" are made for.
Well, to continue down this avenue of argumentation: If you're using hashes, then isn't it also likely that you know all the names of the keys in advance? Then you could do $db->select( my_table => ['price',...] )->hashes. Then you wouldn't be getting more columns than necessary when your table definition changes, you'd get hard failures instead of unexplained undefs when your column names change, and so on. I know that listing all columns feels tedious, but I tend to agree that SELECT * is brittle, and IMHO one solution is having the column names in Perl variables and then building the queries instead of hard-coding the SQL.
Plus, query building with SQL::Abstract means you can do fun things on the Perl side like using map to easily apply the TO_CHAR function to multiple columns, something like $db->select( my_table => [ map { \["TO_CHAR(?,'YYYY-MM-DDTHH24:MI:SS') AS ?",$_,$_] } @datetime_columns ] ) (untested).
Yet another idea might be to look at extending Mojo::Pg::Results's expand method, which already processes JSON columns, you could use this to convert date/time columns to DateTime objects automatically. The "advantage" of this solution would be that you could continue using SELECT *...
| [reply]
[d/l]
[select] |
Okay
Let's continue.
Your arguments are valid. You also gave me some ideas about SQL::Abstract.
My idea was that I have a few levels where the data is handled. When the need arises to add a column, I need not change the code which retrieves the data from the database, because it will, thanks to the * give me all columns. And this might not be just one function, but several.
I only need to change those functions, which have to handle the new column.
s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
+.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
| [reply]
[d/l]
[select] |
I only need to change those functions, which have to handle the new column.
Sure, though I think you'd still have a problem if a column gets renamed? But don't get me wrong, I'm not fixated on this argument against SELECT * - you know your database better than I do, so it may be possible for you to say now that columns will never get renamed and adding columns will be rare, even in the future. I just have been enjoying writing code using SQL::Abstract via Mojo::Pg, and I see several advantages over hard-coded SQL (there are of course disadvantages too, like slightly more verbose code in certain cases, and I assume the performance is not as good when compared to hard-coded SQL). I do still have a few hard-coded SQL statements in my codebase too.
| [reply]
[d/l] |
