populate Plate Mapper test db #626
Conversation
There was a problem hiding this comment.
I made some comments. Since this is just so we have some data for running the tests it is ok to leave as it is, but I just made the comments for your information, but once we decide to merge this into master, lines 292 to the end should be removed and we should add the SQL code that transfers the google doc information. This is not critical at this moment and can be done later, although this is an easy parallel task that somebody else can do.
|
|
||
| -- Migrate data from barcodes to pm | ||
|
|
||
| INSERT INTO pm.sample (sample_id) |
There was a problem hiding this comment.
@qiyunzhu I thought in previous discussions we decided to not transfer the barcodes to the sample table but rather use the barcode table as a lookup table later?
There was a problem hiding this comment.
@josenavas I remember that our plan was: For AG samples, sample ID == barcode. For non-AG samples, there is a different form of sample IDs. Therefore I had barcodes transferred into pm.sample. It looks to me that the dbSchema you and I designed also reflects this. I don't know what is a lookup table, though. I just Googled this term.
There was a problem hiding this comment.
That is correct. However, not all barcodes that are in the table barcode.barcode are going to be plated. Long story short, some of the barcodes get lost, samples never get logged in, etc... Thus, the point would be to add those barcodes to this table only when it is needed. Does it make sense?
There was a problem hiding this comment.
Yes it makes sense. Let me think how to implement it.
There was a problem hiding this comment.
It is going to be really hard to automatically detect if a sample is barcoded or not - so I suggest using user-input to know if the sample is barcoded or not, and in case that it is, you can check if it exists on the barcode.barcode table.
|
|
||
| UPDATE pm.sample SET barcode = sample_id; | ||
|
|
||
| INSERT INTO pm.study (qiita_study_id, title) |
There was a problem hiding this comment.
This is not correct, the barcodes.project do not have the same meaning that the study_id here. The study id should be the one from Qiita.
There was a problem hiding this comment.
I think our previous discussions were: A study in plate mapper has its unique incremental study ID. The study can be imported from Qiita, in which case there is an additional qiita_study_id. Or, it can be non-Qiita (e.g., AG), in which case there is no qiita_study_id. In the very beginning you proposed to use positive number as Qiita study ID and negative number as customized study ID. During later discussions on GitHub we changed the plan and added the qiita_study_id column.
There was a problem hiding this comment.
Note that your insert here is using qiita_study_id = barcodes.project.project_id. Note that the barcodes.project.project_id is NOT the Qiita study id, and hence that is why doing this is incorrect.
There was a problem hiding this comment.
Oh. Got it! Minor question: If we don't import this project ID somewhere, in the future it may be gone after the barcode schema is retired. Will that cause problem?
There was a problem hiding this comment.
The barcode schema is not going to be retired. It is really important for the American Gut website. Remember that this database is powering the labadmin site AND the american gut participant portal.
|
|
||
| -- Migrate data from barcodes to pm | ||
|
|
||
| INSERT INTO pm.sample (sample_id) |
There was a problem hiding this comment.
@josenavas I remember that our plan was: For AG samples, sample ID == barcode. For non-AG samples, there is a different form of sample IDs. Therefore I had barcodes transferred into pm.sample. It looks to me that the dbSchema you and I designed also reflects this. I don't know what is a lookup table, though. I just Googled this term.
|
|
||
| UPDATE pm.sample SET barcode = sample_id; | ||
|
|
||
| INSERT INTO pm.study (qiita_study_id, title) |
There was a problem hiding this comment.
I think our previous discussions were: A study in plate mapper has its unique incremental study ID. The study can be imported from Qiita, in which case there is an additional qiita_study_id. Or, it can be non-Qiita (e.g., AG), in which case there is no qiita_study_id. In the very beginning you proposed to use positive number as Qiita study ID and negative number as customized study ID. During later discussions on GitHub we changed the plan and added the qiita_study_id column.
|
@qiyunzhu note that although we are having a discussion in here, I don't want you to do any changes in here, since this is just temporal data used so we can easily test your progress on the interface development. Before merging this into master we will remove those lines and add all the SQL query needed to populate the DB with our previous knowledge (currently stored in google docs). |
|
@josenavas That's good! I was just thinking to how use a single SQL command to do all those. Must be very hard. As you said, they are just temporal data. |
|
@antgonza Thanks! |
No description provided.