Duplicate column names

[ForbesLindesay]

If a query returns duplicate column names, it is impossible to get all the values out of a record. It would be useful to have a property of the record that allowed you to access the raw list of field values as an array.

[danpetitt]

I would have thought that would be bad practice anyway as you should use aliases in your SQL for those situations.

[ForbesLindesay]

Possibly, but I just had someone else write a query that did this and it caused a strange bug in my app. Another alternative would be to throw some kind of error?

The use case that is getting the right headers on a report, something like:

key	section 1	value 1	value 2	section 2	value 1	value 2
foo	Section Header	1	20	Section Header	5	3
bar	Section Header	3	25	Section Header	6	1

[sidorares]

It's should be doable right now - https://github.com/felixge/node-mysql#joins-with-overlapping-column-names

[felixge]

Yes, the link provided by @sidorares should explain the solution for this problem.

[ForbesLindesay]

That only works when the columns come from different tables. It doesn't work when all the fields are calculated columns from the same table.

[sidorares]

@ForbesLindesay you can always rename row in sql with value2 as baz. Alternatively we can have flag to output rows as an array instead of hash

[ForbesLindesay]

A flag to output as an array instead of a hash would be really useful. The reason for this is that I use the column names directly as part of the report shown to the user so renaming them to random different things doesn't really completely solve the problem.

[sidorares]

@felixge - your thoughts? It's easy addition, I'm probably +1 to "rowsAsArray" client flag

[felixge]

@sidorares sure, an rowsAsArray option for the query() sounds great. Happy to merge a patch if somebody wants to implement it.

[sidorares]

@felixge I can do this. should be in v2.1 imo as it's a new api. What do you think about 2.0 release?

[felixge]

@sidorares I don't have time right now to cut a 2.0 release, but if you want to go ahead with it - go for it.

As for future version numbers: Incrementing to 2.x for new features makes sense. 3.x will be reserved if we have to make b/c breaking changes, but I'd like to avoid doing that unless we have very good reasons.