send full config to config rows

[odinuv]

U nekterych komponent (nejvic gd writer) zapasime s tim, ze na ne nejde dobre pouzit config rows, tak me napadlo, ze by mozna bylo resenim, kdyby komponenta dostala celej config. Tzn. dejme tomu, ze by byla flag komponenty needsFullConfig a potom by config.json pro komponentu vypadal treba takhle:

{
    "storage": {"input ...},
    "parameters: "{"foo:": "bar"},
    "parent_config": {
         "storage": {"input ... },
         "parameters": "{"foo": "baz"},
          "rows": [
                "storage": {"input ... },
                "parameters": "{"foo": "barKochba"}
          ]
}

tzn. komponenta by dostala moznost vyzobat si co potrebuje z parent configu, soucasne by ale platilo, ze v config.json je obsah aktualniho row. Pro jednoduche komponenty je to k nicemu a zbytecne by to nafukovalo a komplikovalo config.json, proto bych to delal jenom na flag.

https://keboola.slack.com/archives/C02CGRFK2/p1569589145007200

[ondrejhlavacek]

co to dát do JSONu (JSONů?) mimo, aby se to ani potenciálně nemohlo jakkoliv zadrbat?

jinak bacha, není to parent. parent je už mergnutej do aktuálního config.json.

aby to pro komponentu bylo co nejjednodušší, přišlo by mi dobrý udělat rows.json, který bude pole standardním postupem pomergovanejch configů pro všechny rows. co je ale blbý je, že nepůjde poznat, kterej z nich je ten aktuální (je to potřeba?).

a nebo to nijak nemergovat ani nemanipulovat a dát do raw_config.json raw response z API včetně metadat a rows a jejich metadat. bude tam i state a podobný srandy, jen bude potřeba to rozšifrovat.

podle mě ale narazíme hnedka v další iteraci na to, že v takovýmhle setupu bude nějaká komponenta chtít měnit state pro víc rows :-(

[odinuv]

tu raw response bych nedelal, protoze to se zadrbeme v tom, ze se pak bude propagovat jakakoliv zmena v api buhvi kam

[ondrejhlavacek]

bez nich přijdem o IDčka a možnost zjistit, která row je ta aktuální.

[odinuv]

a tak muzes si tam dat IDcka, kdyz ti to udela radost :)

[ondrejhlavacek]

myslíš, že to je potřeba?

[odinuv]

spis bych mel tendenci rict, ze ne. ale mozna mas pravdu s tim, ze to muze byt vedle v nejakym config_full.json.

V podstate mame podle me potencionalni usecasy jen v gd writeru, pripadne v jinych writerech, kde je nejaka referencni integrita. Tzn. prijde mi, ze na tohle dneska chybi moznost spustit tu konfiguraci celou (protoze dnesni spusteni cele config rows konfigurace je jen skryta iterace nad tema rows). To samozrejme trochu rusi tu vyhodu config row v tom, ze ta komponenta nemusi o te konfiguraci premyslet, ale muze si vybrat.

[ondrejhlavacek]

Snowflake DWHM by na tom mohl dost dobře taky benefitovat pro decomissioning uživatelů. Chtěl bys tohle předávat i do sync akcí? (IMHO jo)

[odinuv]

jj. jj i do sync akci

[ondrejhlavacek]

taky si myslím, že to ID není potřeba. takže za mě ✅

[kacurez]

len dodam ze treba mat na pamati ze ak bude mat komponenta ten needsFullConfig flag tak sa musi pustit len raz tj neiterovat po config rows.
A ako to bude vypadat ak sa pusti single config row run pre taku komponentu? - v tom pripade jej musi byt nejak "povedane" ze nema nacitat config_full.json ale config.json kde je ten konkretny row imho. Pre gd writer si viem predstavit ze by pre single row run tam nemusel byt config_full.json a potom by fallbackoval na config.json ale zas ten by mal asi inu strukturu.

[ondrejhlavacek]

aha, tak tohle jsem nepochopil (nebo nedočetl)! v čem se liší single row run od all rows run?

[ondrejhlavacek]

spíš mi přijde, že to jsou dva rozdílný joby - multiload a (iterativní) single load, který dělá jedna komponenta.

[kacurez]

Ja to chapem tak ze komponenta potrebuje k pusteniu konfigu kontext a specialny handling ktory jej docker runner nemoze dat, preto si poziada vzdy o vsetky rows a rozhodne a vykona sama ako to pusti(paralelne alebo po jednom).
single rows run vs all rows run - to by imho malo platit ako doteraz, takze sa jej posle len jeden row ale mozno tam bude stymto flagom problem, to je zas iny kontext, a mozno to doiteruje k tomu ze sa komponente explicitne povie ze to je single run row. U gd writeru si to viem predstavit ak by bol cely gd model v root konfigu a v config rows iba input mappingy tabuliek tak by pri pusteni single row nebola narusena referencna integrita imho

[kacurez]

este dodam ze napr u gd writeru pre single row run akcia multiload nedava zmysel