Add alias option to every analysis node

[saleiva]

Right now, the name of the tables created by the analysis nodes changes every time the parameters of the analysis change. An alias will be a -unique- name that you assign to an analysis node, so you can query that node always in the same way.

In Terms of UI this would be simple. Just adding an extra block for the alias on the analysis config and putting that alias on the layer list as the id of the node.

[alasarr]

+1

[javisantana]

@rochoa we need to discuss this at API level

[malkab]

+1, definitively. This is a breakthrough improvement.

[rochoa]

A couple of questions:

• Do you expect the alias to be the same when you change some of the params?
• Do you expect the alias to remain the same when some filters (from a widget) are applied?

---

Imagine you have a metro station points dataset.

You create a couple of different visualisations where you end having the same buffer, let's say 500m over each station, the nodes are in both visualisations are:

1. [a0: stations] -> [a1: buffer 500m] -> [a2: intersection a1, b0].
2. [b0: stations] -> [b1: buffer 500m] -> [b2: intersection b1, c0].

Now, from your proposal: what would you expect as the alias for the buffer in both cases?

---

In general, and related to @javisantana comment, is the alias something persistent or is something you want to have temporarily as you are working with it?

[saleiva]

From my understanding it should be persisted.

On Aug 1, 2016 1:14 PM, "Raul Ochoa" [email protected] wrote:

A couple of questions:

• Do you expect the alias to be the same when you change some of the
  params?
• Do you expect the alias to remain the same when some filters (from a
  widget) are applied?

---

Imagine you have a metro station points dataset.

You create a couple of different visualisations where you end having the
same buffer, let's say 500m over each station, the nodes are in both
visualisations are:

1. [a0: stations] -> [a1: buffer 500m] -> [a2: intersection a1, b0].
2. [b0: stations] -> [b1: buffer 500m] -> [b2: intersection b1, c0].

Now, from your proposal: what would you expect as the alias for the buffer

in both cases?

In general, and related to @javisantana https://github.com/javisantana
comment, is the alias something persistent or is something you want to have
temporarily as you are working with it?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#9113 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIENVY0Vsm96D1tUzsfxWLuC9thBy2_ks5qbdT_gaJpZM4JVBbi
.

[rochoa]

Then, what about the rest of my questions?

[saleiva]

Yes to both IMO

[rochoa]

Current implementation gives you back the query associated with the node name. So nothing stops us from having an abstraction at client side to ask for the query associated with a node. But that should be also considered when we define the API at client side.

I don't think it's possible to make it persistent and at the same time keep the same alias when params and filters change.

For me, it starts to look like Named Analyses, à la Named Maps, so as @javisantana was pointing, we should think about the problem we want to solve at API level because this is a higher level abstraction over what we have now.

[malkab]

Hi everybody from Geographica!

Any further progress / thoughs / planning about this? IMHO, this is a great improvement to mix Builder tools with custom SQL. Also great to test new and potential Builder tools algorithms.

[javisantana]

This should be though with Analysis API -> CartoDB/Windshaft-cartodb#559

[stale]

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.