-
Notifications
You must be signed in to change notification settings - Fork 6
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
Refactor of database tables and api related core utilities #181
base: pathoweb-core
Are you sure you want to change the base?
Conversation
@@ -141,5 +141,172 @@ | |||
"name": "RelecovManager", | |||
"permissions": [] | |||
} | |||
}, { | |||
"model": "core.errorname", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
para mi estos errores no deberían ser errores de código de python, sino errores de la "interpretación" del error, por ejemplo si da error porque el json que se sube a la base de datos la key es "LINEAGES" y en realidad tiene que ser "lineages" el error de python sería Key not found, pero nuestro error aquí sería: Wrong format in json data uploaded to db, o algo así. No sé si me explico
return error_name_obj | ||
|
||
|
||
# TODO: Would it be possilbe to return a serializer object instead? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sí, depende para lo que se utilice luego puede ser más útil, en este caso me parecen bien ambas porque en ambos casos es un objeto. Donde siempre tenemos que devolver o serializer o objeto es cuando se devuelve un diccionario custom por ejemplo, ahí es mejor devolver el objeto para ya coger la información que necesites, y no tener que aprenderse de memoria la estructura de 200 diccionarios
} | ||
meta_value_serializer.save() | ||
|
||
return {"SUCCESS": "success"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
esto tenemos que hablar y llegar a un acuerdo de cómo utilizar este tipo de estructuras, porque esto me rechina un montón de siempre
core.api.utils.common_functions.add_sample_state_history( | ||
sample_obj, | ||
state_id=state_id, | ||
error_name=None, # TODO: do not know what to do with this at this point |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aquí sigue siendo sin error no? no entiendo el TODO, siempre tendríamos que tener error 0 de base y si hay un error en algun Except que se sobreescriba al que sea
@@ -41,7 +41,7 @@ class BioinfoMetadataFile(models.Model): | |||
created_at = models.DateTimeField(auto_now_add=True, verbose_name=("created at")) | |||
|
|||
class Meta: | |||
db_table = "core_bioinfo_metadata_file" | |||
db_table = "core_metdata_values_file" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
db_table = "core_metdata_values_file" | |
db_table = "core_metadata_values_file" |
PR Description
This PR refactors the database structure and related API utilities to streamline models and relationships based on the updated design (see #176 ). Key changes include:
1. Sample State Tracking (#180 ):
SampleStateHistory
to replaceDateUpdateState
.2. MetadataValues Table (#177 ):
BioinfoAnalysisField
withMetadataValues
to consolidate metadata relationships.3. Lineage Removal (#179 ):