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

[ondrejhlavacek]

čím se teda liší single row vs multiload? pokud je single row run validní, tak stejně tak validní je single row run pro všechny rows po sobě, ne? (současný config rows chování). a pak je tam multiload, kterej musí zpracovat všechno naráz (a k tomu musí mít i všechny input mappingy?)

[kacurez]

v pripade multiload pusti docker runner komponentu len raz, v pripade single row pusti komponentu tiez len raz takze z tohto pohladu sa nelisia nicim. Rozdiel je v tom ze jednak docker runner nepozna multiload takze to je to z jeho pohladu rovnake ako single row run a hlavne komonenta naopak nepozna single row run teda nevie otom ci bola pustena ako single row alebo cely konfig nie? Vzdy otvori rovnaky config_full.json a tam najde vsetky rows, preto ma zaujimalo ako sa jej povie ze ma pusti len jeden row v pripade ze bola pustena ako single row run.

este dodam ze v pripade gd writeru sa to lisi aj volanim api, multiload ma proste iny api call na gd api ako single row run.

[kacurez]

alebo to je tak ze budu vzdy config.json + config_full.json a komponenta pozera do config.json a z config_full.json si len domerguje chybajuce info a zaroven sa vzdy pusti len raz tj docker runner neiteruje nad config rows aj v pripade full runu?

[ondrejhlavacek]

#438 (comment)

no to právě myslím tím, že je to jiný typ jobu. mají stejný config a chovají se jinak.

[odinuv]

no to co mysli kacurez je zase to, ze kdyz das run na konfiguraci s config rows, tak automaticky iteruje pres kazdy row, cili by to muselo byt spojeny s nejakym run-single asi, coz je asi to, co myslis ty :)

[ondrejhlavacek]

no tak nějak :-) imho bychom mohli mít víc typů jobů na komponentu, ale radši bych se do toho nepouštěl, otevírá to hodně nebezpečný dveře. normálně bych radši řekl, že tu stejnou konfiguraci můžou použít dvě komponenty - jedna čistě na multiload a druhá na ty iterace přes rows.