Excecuting Gregor step1 and step2

In [1]:

%%capture
# load the magic extension and imports
%reload_ext nextcode
import pandas as pd
import GOR_query_helper as GQH
%env LOG_QUERY=1

project = "gdx-demo"
%env GOR_API_PROJECT={project}

Gregor YML¶

Running Step1 & Step2¶

One way to run the main business logic in Gregor is simply to call the YML code directly from within GORdb, i.e. to parameterize the query statements through the YML. The following is the entire code for that:

In [2]:

%%gor

def #refresh# = signature -timeres 1000;

create #gregor1# = gor user_data/GregorTraining/gregor_step1.ftl.yml(index_case = 'DEMO_2796799',father = 'DEMO_2827751',
                       mother = 'DEMO_2796810', gor_or_pgor = 'pgor') | #refresh# ;
    
create #gregor2# = gor user_data/GregorTraining/gregor_step2.ftl.yml(index_case = 'DEMO_2796799',father = 'DEMO_2827751',
                       mother = 'DEMO_2796810', prepopulated_result = [#gregor1#] ) | #refresh# ;

nor [#gregor2#] | top 1
    
    

Query ran in 4.61 sec.
Query fetched 1 rows in 15.58 sec (total time 20.18 sec)
                                             

Out[2]:

	CHROM	POS	Reference	Call	zygosity	sequence_variant	Gene_Symbol	auto_classification	auto_evidence	GDX_view	...	Refgene	ref_af_cust	rsids	spliceai_max_consequence	transcript_source	trigger50bpRule	var_type	VEP_Impact	vep_max_impact	VEP_Max_Score
0	chr1	906082	C	T	het	chr1:906082C>T, het, PLEKHN1, NM_032129.3:c.42...	PLEKHN1	LB	BP4	NaN	...	NM_032129	0.0	rs373726748	NaN	no_source_detected	0	sub	MODERATE	MODERATE	0.711

1 rows × 184 columns

What we see above are two create statements. The output from the first, #gregor1#, is passed into step2 as the value file for prepopulated_result. Here we have also defined #refresh# to cause re-execution of the YML steps, because currently, GORdb does not automatically trigger execution of queries if the timestamp of the YML file has changed (unlike what it does with regular data source files).

In [ ]: