Dataset privacy and shared visualizations

[simon-contreras-deel]

We are going to add a new feature allowing users to share visualizations and in the first approach, we are going to allow only public datasets.

So, at least, we need to know the dataset privacy to check if it is public or not. Take into account when we use the Dataset upload method, we are creating a private dataset in CARTO. And also, the problem with ghost tables https://github.com/CartoDB/product/issues/336

We will need to decide on the implementation time if we go to full integration of the datasets' privacy functions allowing to change the privacy, but it is not required to finish the issue.

Related issues / even projects:

• Change dataset privacy after write #579
• https://github.com/CartoDB/product/issues/336

[simon-contreras-deel]

The first step is to add the carto-python Dataset to the equation.

@alrocar and I have talked in the past about it. But my approach has diverged a little bit: I still think is useful to have a _metadata property, but I think is not a good option to have a getter and setter for it. I prefer to keep it private and then add specific methods to access specific metadata properties like privacy which would have public get_privacy and set_privacy methods like that ---> https://github.com/CartoDB/cartoframes/pull/691/files

How do you see it @alrocar @andy-esch @ethervoid ?

[ethervoid]

I want to answer with a question. What are we going to do with the metadata object apart from getting the privacy?

[simon-contreras-deel]

Now nothing. In the future, we would want to add tags for example (really there is not much more interesting from the user point of view)

[ethervoid]

If we're going to act in a few elements of the metadata I agree with encapsulating that properties to have more control over them but only if we have a reason for it (keep control of the metadata updates for example)

[simon-contreras-deel]

We need the carto-python Dataset class to make requests to the visualization API (which is still private by the way), to change the privacy for example

[alrocar]

One advantage of wrapping the carto-python Dataset methods is that you won't expose any changes on that dependent module API to the CARTOframes users. Most likely we won't change the current /viz API but create a new public API at some point, so it makes sense keeping CARTOframes away of these changes.

Wrapping every single property in a method would lead to making several requests to the actual /viz API when you want to update several attributes (let's say you want to update the name of the dataset, the privacy, tags, etc.), instead of a single request. So I would consider, in any case, having a helper method to update_metadata(privacy = None, name = None, etc.) with a few properties.

Maybe we can just, wrap the minimum necessary attributes we think a CARTOframes user needs to work (changing privacy as @oleurud suggested) and then in the API docs or developer center, refer to the carto-python Dataset for more fine grained control over the dataset metadata, with examples and so on.

My 2 cents.

[simon-contreras-deel]

I don't really like to use words like metadata which is a CARTO business word, with a meaning for us, but not necessarily the same for a user, in my opinion. But I think @ethervoid was thinking about it in a similar way.

About the API¡ which is not public, we are currently sending a warning message: FutureWarning: This is part of a non-public CARTO API and may change in the future. Take this into account if you are using this in a production environment. Should we remove it from carto-python? Should we do the API public? @javitonino

[simon-contreras-deel]

I have talked with @javitonino offline about the message: go ahead without changing anything because we are goin to handle the API in a sort/medium term, probably before CARTOframes v1.0

[alrocar]

I don't really like to use words like metadata which is a CARTO business word, with a meaning for us, but not necessarily the same for a user, in my opinion. But I think @ethervoid was thinking about it in a similar way.

Yes I agree, my point was more about avoiding to update several attributes one by one :)

[ethervoid]

Yes I agree, my point was more about avoiding to update several attributes one by one :)

In that case we can encapsulate that update for multiple attributes into one meaningful method

[simon-contreras-deel]

Oki, a meaningful method then. Now I need to find a nice word to use

[simon-contreras-deel]

I forgot to say: thank you :)

[alrocar]

Oki, a meaningful method then. Now I need to find a nice word to use

We leave the difficult part to you (not a joke)

[simon-contreras-deel]

We have a really big PAIN here (as @alrocar warned here: https://github.com/CartoDB/product/issues/336), with the time needed between table creation and the visualization creation:

• sometimes, it takes more than 20 seconds, especially with FREE users. So, imagine a user playing with data, creates a map and publish it for sharing it. We will need to save the data, wait all this time to change privacy (from private to public) and then continue with the publication.
• running a get metadata test, as they are end to end right now, it could take ages (maybe we could create a permanent table and ask for it always 💩 )

[simon-contreras-deel]

🚀