Cartodb: feature request: add a 'sql behind this analysis' expand-and-see to show sql in onboarding

[andy-esch]

To encourage people to use SQL/PostGIS/crankshaft functions, it'd be pretttty killer if there was the following:

1. Apply an analysis
2. On success in the on boarding screen, we should have an expanding section ('show query behind this analysis') that allows the user to see the underlying query applied to create the analysis table (that is, just show the templated camshaft node) to show that more customization/power can be obtained through the sql panel if desired

I like this because CARTO has always been a great tool to encourage and teach SQL/PostGIS usage, and the 'show query behind analysis' educates people that these functions are available through engine.

cc @javierarce @rochoa @stuartlynn @zingbot

[saleiva]

Yep, interesting... What I would actually love is to show that SQL on the SQL panel of the layer, even if its READ ONLY.

[javisantana]

The thing is:

• autogenerated SQL will mean nothing to the user. It's hard because of parameters.
• most of the times SQL selects an intermediate tables and it's impossible to understand if you don't know the internals. Translating it to a human readable format is not easy.
• analysis can be executed by a non sql thing. Using plpython was not a good idea, we are having a lot of problems that we wouldn't have if we had used just python inside camshaft. We have facing crazy issues right now and I think we will need to get rid of cranshaft (particurally the plpython part). This also will help us to fix one of the problems we have right now, scalability, and will help us to integrate other interesting stuff like R.
• having a mix of sql and custom filtering and analysis is adding lot of limitations from the technical point of view

cc @rochoa

[stuartlynn]

@javisantana How would we run python inside camshaft? Just spawn a new process from node that runs the python code and returned the results? How would such a script have access to the database or the input data? Would be good to talk more about this cause I agree that there are problems with plpython.

[andy-esch]

I agree -- plpython is a huge headache and really slow to develop. Whatever form the camshaft analysis takes, it'd be great to educate the user about some of the internals (like I said above) because in my experience exposing the SQL and CartoCSS has been a gateway into coding for tons of people I've talked to since I started at CartoDB, and that has good implications for API/Engine usage

[javisantana]

we are still thinking, not a short term thing, I want to learn more about the usage and then redo it.

My point is: we should provide a framework to add analysis based on python and R not tied to plpython and that will run in camshaft, postgres or any other platform

[stuartlynn]

Sounds great. I would love it if we could be part of scoping that out, I think we can help provide some insight / requirements.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.