CartoDB
aggregate-intersection column name collision
If one of the input nodes has already a count_vals column the count(_cdb_analysis_target.cartodb_id) AS count_vals, will collide with it.
This is not only related to aggregate-intersection but in general a problem to all analyses.
We need to provide a general solution to the problem, so we avoid column name collisions.
cc @javisantana @dgaubert
One option is to allow someNode.getColumns() to receive a list of columns you don't want to get, the simpler option is to filter the potential collisions in each analysis.
I don't see a good solution, we could name columns with some analysis prefix but that could lead to the same problem.
Overriding would be a possible solution but that could be missleading for the user
With a prefix by type (e.g: buffer.count_vals), if user creates an analysis with same kind of analysis twice will also collide. We will need a prefix with a random o unique value and this also could be misleading for the user.
I'm re-activating this issue since it's been giving us a lot of headaches in Solutions recently, and a prospect has been complaining about it as a reason not to buy CARTO. His is a classic use-case: SB ticket.
We regularly use some workarounds like exporting, changing name and importing back, but this is obviously not a dynamic solution.
Not sure how to implement these but some ideas we had are:
- Rename analysis columns if coincidences are found (
count1,count2...) - Allowing manual column naming, like in the DO enrichment analysis.
What would really make this analysis amazing would be the option to select multiple fields for aggregation and appending them all to the dataset. Once again, no idea how feasible this is.
Another great feature would be to keep the geometries that don't intersect, as explained by @andy-esch in this issue. We constantly have to add the polygon layer again, then LEFT JOIN the Aggregate intersection results to it in order to keep all the polygons.
I'm opening a new ticket #330 for a solution to this that we can also apply to other analysis nodes as needed. (note that this could happen also with other analysis, and even in this one not only for count_vals, but for other aggregated colums too).
