Skip to content

Conversation

@ahmadazd
Copy link
Contributor

First version of the dashboard
fetching reads and sequences from advance search ( public data only )

fetching the rest of the reads ( cancelled, suppressed and private) from ERAPRO

Graph tab contains Public reads and sequences

Stats tab contains only reads ( public, private, suppressed, cancelled)

First version of the dashboard
fetching reads and sequences from advance search ( public data only )

fetching the rest of the reads ( cancelled, suppressed and private) from ERAPRO

Graph tab contains Public reads and sequences

Stats tab contains only reads ( public, private, suppressed, cancelled)
@ahmadazd ahmadazd self-assigned this Apr 26, 2022
cx_Oracle.init_oracle_client(lib_dir=client_lib_dir)
connection = None
try:
dsn = cx_Oracle.makedsn("ora-vm-009.ebi.ac.uk", 1541, service_name="ERAPRO")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is a public repository, maybe best to put the database information in a config YAML file and retrieve them from there before calling here. In the GitHub repository, you'd have an empty config file, but your local one can include the information. This way we won't be exposing the database information.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably good practice, but here we've only got readonly access information, plus the dbs are behind the firewall, so it's probably not really too risky.

Copy link
Collaborator

@nadimm-rahman nadimm-rahman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really good! Just one suggestion, as I commented, which is about the best way to handle the database connection information. Let me know if you have any questions or need any clarifications.

Generally, I think in the future, you can even start to implement one or two class objects, as there are a number of functions which call each other. But this can be for later down the line in the future.

@carlacummins
Copy link
Contributor

carlacummins commented Apr 29, 2022

This dashboard might be better off as a standalone repository, rather than as part of this repo (unless there's scripts here that you're calling within your app? I couldn't see any at first glance). At the very least, it should all go into its own directory, e.g. scripts/tracking_dashboard/.

Additionally, dashboard.py is a pretty huge script! I would definitely recommend pulling out some of the defs and putting them into a file by themselves, e.g. utils.py. You can then still use them within dashboard.py by doing a from utils import * at the top. This leaves the code a bit more readable/maintainable. Example here from a very basic dashboard I was playing around with: https://github.com/carlacummins/dash-ena-cv19

if x == y:
df_mod.at[x, column_x] = np.nan
return df_mod

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost everything above here could move to utils.py (or whatever you want to name it)

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

Successfully merging this pull request may close these issues.

4 participants