You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.
As a useful extension, we can add functionality to create an object from database content. For example, this can take an entry from the sources table and add all data from all other tables that refer to it. This could then be serialized as an xml, json, or yaml file that can be used to transfer the object from one database to another. While this functionality is similar to db.inventory(), by exporting to a file we can easily share all data for a single object. This has applications beyond astrodbkit (imagine, for example, a button on Simbad that would grab all the relevant data for the object you've searched in a format that can be quickly imported to a database), but can be prototyped as part of astrodbkit for purposes of database object transfers. There are ways to transfer information between databases with SQL, but this object-orientated approach can in principle simplify the process by consolidating all information from associated tables.
We'll need at least two methods: one to read the data and one to write it to the database.
Some questions to consider:
How do we store the object contents in memory? A list of astropy.Tables? Dictionaries? Custom-built Classes?
If a custom-built Class, should this generalized and moved outside of astrodbit?
How do we serialize this? Should we pick a format (eg, xml) or allow the user the choice?
Should primary keys or identifiers (eg, source_id) be preserved?
How should we track data integrity? While more of a long-term issue, calculating something like checksums per table/row could allow us to ensure that the data being written to file is the same as what was in the database.
This has the potential to be a rather large project with important ramifications, so this issue is meant to be more of a sounding board and to provide a starting point for work during hack/sprint sessions at conferences.
The text was updated successfully, but these errors were encountered:
As a useful extension, we can add functionality to create an object from database content. For example, this can take an entry from the sources table and add all data from all other tables that refer to it. This could then be serialized as an xml, json, or yaml file that can be used to transfer the object from one database to another. While this functionality is similar to
db.inventory()
, by exporting to a file we can easily share all data for a single object. This has applications beyond astrodbkit (imagine, for example, a button on Simbad that would grab all the relevant data for the object you've searched in a format that can be quickly imported to a database), but can be prototyped as part of astrodbkit for purposes of database object transfers. There are ways to transfer information between databases with SQL, but this object-orientated approach can in principle simplify the process by consolidating all information from associated tables.We'll need at least two methods: one to read the data and one to write it to the database.
Some questions to consider:
astropy.Tables
? Dictionaries? Custom-built Classes?This has the potential to be a rather large project with important ramifications, so this issue is meant to be more of a sounding board and to provide a starting point for work during hack/sprint sessions at conferences.
The text was updated successfully, but these errors were encountered: