Cartodb: Deprecated SQL Function analysis UI

[rochoa]

To support https://github.com/CartoDB/camshaft/pull/280 at builder level, we need to pull a new UI for it.

cc @xavijam

[rochoa]

Our initial proposal would be something like:

[saleiva]

Like this :dab:

I don't think we need more designs since this will be automatically generated.

[saleiva]

cc/ @noguerol @xavijam

[xavijam]

Whatever we decide, let's not forget the onboarding text and the animation.

[saleiva]

Not sure we can have an onboarding text since it will depend on the function... About the animation. Ok, we can prepare something quick

[noguerol]

Update: we have just decided we will have no animation nor onboarding.

[xavijam]

Before doing this task, this ticket is absolutely necessary.

[xavijam]

Basically this analysis will let the user use a function "created" in the DB with parameters. The use case is how @saleiva and @rochoa have explained it.

• We need to make a query in order to take all the available functions under the user (query will be done by @rochoa 💋 ).
• That query will give us three things:
  
  
  
  • the name of the function.
  
  
  • the name of the arguments accepted.
  
  
  • the type of the arguments accepted.
  
  
• With that, the second part of the form will be created, giving the user the possibility to fill up all those arguments and launch the analysis.

That's all!

[rochoa]

The query is ready: https://github.com/CartoDB/camshaft/blob/ca43718cc25563d491f27616a3c7891439171b51/docs/deprecated-sql-function.md#query-to-retrieve-metadata-about-compatible-functions.

@xavijam, can you check it contains the required information for your needs?

When requested through the SQL API, you will get something like:

{
  "fields": {
    "has_secondary_node": {
      "type": "boolean"
    },
    "fn_name": {
      "type": "name"
    },
    "params_types": {
      "type": "string[]"
    },
    "params_names": {
      "type": "string[]"
    }
  },
  "rows": [
    {
      "has_secondary_node": false,
      "fn_name": "dep_ext_buffer",
      "params_types": [
        "number"
      ],
      "params_names": [
        "radius"
      ]
    },
    {
      "has_secondary_node": true,
      "fn_name": "dep_ext_spatialinterpolation",
      "params_types": [
        "string",
        "number",
        "number",
        "number"
      ],
      "params_names": [
        "val_column",
        "method",
        "number_of_neighbors",
        "decay_order"
      ]
    }
  ],
  "total_rows": 2,
  "time": 0.03
}

[xavijam]

Yep, looks like it is ok! One question, the order of the params_name is the one the analysis API is waiting to receive?

[rochoa]

Yes.

[ivanmalagon]

Even not having animation nor onboarding I think we need some graphic to show in the analyses view.

If not, it feels unfinished. Perhaps only a graphic like y = f(x) in the same colors as the rest (but no animation).

What do you think @saleiva @noguerol ?

[xavijam]

My opinion: add an image saying "[SQL]" or "[Function]".

[saleiva]

+1 to that. @CartoDB/design any quick idea?

[urbanphes]

Maybe we can make it as a typewriter. As if the text is written.

[ivanmalagon]

Hi.

While developing this ticket I run a lot of times into problems while sending the analysis parameters. As they're dynamic we can't force validators. We don't get the custom validation for every field. So it's quite easy to send a badly formed analysis if you don't know the nature of the analysis.

These analyses errors were swallowed. I've modified the visualizations error notification to show the actual error message. Until now, It showed a generic body Please refresh the page and contact us if the error persists. Now, the error gets appended.

I don't know if there were a reason to not show the actual error but the generic message. Showing the actual error has helped me a lot to get this issue up'n'running since I didn't have any idea about the SQL function behind.

If you know about any reason not to show the message, please tell me.

[xavijam]

cc @alonsogarciapablo

[alonsogarciapablo]

These analyses errors were swallowed

Maybe these errors could be properly categorised by Maps API? This way they'll be properly displayed in the UI (as errors on the particular analysis node).

[ivanmalagon]

I've made the changes for that error visualization at this PR

[xavijam]

PR: https://github.com/CartoDB/cartodb/pull/12036

[xavijam]

DEEEEEPLOYED!