Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch between working directories #2

Closed
carlosms opened this issue May 2, 2019 · 4 comments
Closed

Switch between working directories #2

carlosms opened this issue May 2, 2019 · 4 comments
Assignees

Comments

@carlosms
Copy link
Contributor

carlosms commented May 2, 2019

From the design doc:

As a user I want to choose the dataset that I will be working with so that I can switch between sets of repositories for different usages

From a previous conversation:

@carlosms

One thing to discuss. If you change the repositories dir, should the Superset DB also change?

i.e. if I start the sandbox with the repos in bblfsh org and I create a dashboard with charts that show certain metrics.
Then I change the repositories dir to work with src-d repos.
When I log in back to Superset, is it expected to have the same dashboard with updated information, or is it supposed to be a clean installation?

@mcuadros

The same dashboards, you should keep the postgresql

But in a later informal discussion it was mentioned that the other scenario might be preferred.
Needs input from @src-d/product @mcuadros @smola

@smacker
Copy link
Contributor

smacker commented May 2, 2019

keep in mind to clean redis no matter do we keep postgresql storage or not.

@ricardobaeta
Copy link

ricardobaeta commented May 2, 2019

I believe the user could benefit from the option to choose from both, keeping the same dashboard with updated information as default.

@smola
Copy link

smola commented May 27, 2019

As discussed in our last Apps sync (https://github.com/src-d/minutes/pull/577), preserving some state between working directories (e.g. PostgreSQL database) and not other (e.g. git repositories) gets quite tricky, and it's quite hard for us to envision the major use cases for each behavior.

So the simplest solution would work for us initially: allow having a completely separate compose project, with no fancy magic regarding state management. We can figure out better for future releases.

@carlosms carlosms transferred this issue from src-d/sourced-ui May 31, 2019
@carlosms
Copy link
Contributor Author

Code and docs already in master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants