Below the visibility, please add "last update field"

[tomas-knap]

"Last update: XX" should be added below "Visibility". It shows the last successful replace. If the DPU was newly created, it shows the time when it was created. XX in Last update is the date (date + hours + minutes + seconds)

[kukharm]

@skodape @janvojt where can i get the last successful replace time? What methods i should use?

[tomas-knap]

Jj, to by se muselo pridat do db, tedy ze by dpu template mela navic sloupec s datem posledni modifikace

[skodapetr]

Ahoj, je to jedna možnost. Druhá by mohla být .. zkusit použít file systém. Ten by si měl pamatovat poslední změnu na souboru. Ale chtělo by to ověřit zda se to chová přes různé OS v pohodě. Možná bych tedy zkusil tuto cestu? Důvodem pro ní je, že nebudeme přidávat k DPU_TEMPLATE metadata do tabulky. Pokud bychom to už činili tak bych možná radši měl vlastní tabulku. Neb u DPU_TEMPLATE se pak dělá to, že se to skladuje vlastně jen u root a ostatní mají tuto hodnotu null a musí se ptát svých předků.

Ale možná s tím bude více problémů než užitku a bylo by jednoduší použít DB. Počkal bych i na názor Honzy co si o tom myslí. (hlavně u té podpory file systémů si nejsem jistý.)

[tomas-knap]

Ten file system imho neni spatny napad. Koneckoncu, kdyz clovek nasazuje novou verzi toolu vcetne core DPUs, tak to delat tak, ze prekopiruje soubory na patricna mista, nedela to vzdy pres GUI.

[janvojt]

Nebolo by lepsie pridat tam viac tych datumov? Ja by som tam kludne dal creation, modification. Dalej by som kludne trackoval aj zmeny na child template ked sa napr zmeni konfiguracia, nielen ked sa zmeni JAR subor. Takze by kazdy zaznam v tabulke DPU_TEMPLATE mal svoj timestamp. Ako pise Petr, tiez by som bol za pridanie tabulky, ktora by mala info o JAR subore (creation, modification). Myslim ze takto som to aj povodne navrhoval v nejakom databazovom diagrame. Ja by som bol teda radsej za DB. Navyse

1. Ked prekopirujes subor, tak sa tam nastavi aktualny datum, nie ten co bol na povodnom subore (aspon u mna je to default spravanie, ktore sa ale da urcite zmenit)
2. Muselo by sa to brat z nejakej sluzby - tato logika by nemohla byt priamo na datovom objekte.
3. Nemohli by sme oddelit zmeny na JAR subore, a zmeny na child DPUTemplate (konfiguracia apod).

[tomas-knap]

Takhle, pokud jste ochotni tam tech datumu pridat vic...

Na te obrazovce :

Bych pridal nekam dolu "Created by: {user} on {creationDate}", kde creationDate by bylo datum vlozeni nebo posledniho replace

Bych pridal nekam dolu "Last Modified by: {user} on {lastModificationDate}", kde lastModificationDate by bylo datum vlozeni nebo posledniho replace.

Na ob razovku:

Bych pridal nekam dolu:
"Last Modified by: {user} on {lastModificationDate}"

---

Tedy, jednak by tam pro DPU templates druhe kategorie (hlavni) byly casy creation/modifikace tech JAR souboru a pak by tam byly i casy modifikace vsech DPU templates.

Ale vidim tam trosku problem s redeploymentem. Kdyz se rozroste pocet DPUs, tak si dovedu predstavit, ze je budu updatovat stylem "nakopiruju JARka skriptem do target/dpu". Nicmene pak se mi spravne neaktualizuji casy. Rozhodne tohle budu delat v pripade core DPUs.

[skodapetr]

Jinak tohle souvisí trochu s issue o zvážení zachování konfigurace DPU pro execution při jeho změně. Tedy možná bych zde upřednostnil osobní rozhovor .. file systém bychom klidně mohli využít právě pro ten první redeploy a pak mít verzovací tabulku, jenž ponese hystorie .. o konfiguracích updatech apod .. ale chtělo by to lehce promyslet.

Honza: 1) to bych přesně řekl že je to chování které chceš, datum poslední změny ne? to kdy bylo vytvořeno .. můžeme to přidat do manifestu v tom jarku .. a načíst z něj možná? 2) mohla by to dodávat facada na vyžádání, getLastModification(DPURecord ... ) 3) to trochu nechápu .. ?

Co se týče té jar-info table ano je to pravda, že takový návrh tam byl a byl tuším i v tom diagramu od Jana.

Nicméně já tím spíše mířil k nějakým obecnějším metadatům, než zrovna času poslední změny. Ale třeba rovnou url ke zdroji (obecnou!) případně přístupovou metodu .. apod (spíše OSGI věci) .. tedy né zrovna historickou table. Ale pokud chceme jít tímto směrem, tak asi jich bude třeba. Další možnost by byla, uložit vše spolu s execution .. tj. pustím execution a tak uložím celou pipeline, všechny nastavení stavy a pod .. potíž je, že tohle už může být pro DB docela "silné kafe". Tj. zda bychom pak spíše nevyužili file systému a prostě to nesypali do execution directory v serializované podobě.

Já vím, že se odvolávám pořád na ten file systém .. ale hold, Virtuoso není zrovna nejvíce kamarádská DB a možná proto mě i odrazuje. Na druhou stranu .. kdyby takovoudle zálohu zvládla udělat DB sama v sql. stored procedure... a pak bychom to dokázali načíst jako klasické enetity objekty .. (tj. přepnout si zda chci zálohy, nebo aktivní) tak by to bylo docela pěkný, ale nejsem si jist zda je to v moci virtuosa a jpql.

[tomas-knap]

Treba probrat pri schuzce

[tomas-knap]

This feature seems to be important, as DPU developer is typically adjusting DPUs couple of times and if having more than one instance of ODCS, he easily forgets where is which version deployed.