Rust - std::ANY alebo lepší návrh?

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #105 kdy: 02. 12. 2021, 06:27:05 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného :)

Mel bys nejakej netrivialni priklad 2?


Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #106 kdy: 02. 12. 2021, 10:01:45 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného :)

Mel bys nejakej netrivialni priklad 2?

ORM modely pro existujici databazi, DB migrace (vetsinou nemusite cist, ale obcas chcete modifikovat).

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #107 kdy: 02. 12. 2021, 11:11:58 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

...

Mel bys nejakej netrivialni priklad 2?

ORM modely pro existujici databazi, DB migrace (vetsinou nemusite cist, ale obcas chcete modifikovat).

Generovane ORM modely je treba schvalovat clovekem?
(Vim ze se to deje... I na mem soucasnem projektu to tak je... dokonce mi tam do entit cpou business logiku.... ale nelibi se mi to a bojuju proti tomu... protoze si myslim, ze je to nepekne a neni to potreba.)
Tem DB migracim asi nerozumim...

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #108 kdy: 02. 12. 2021, 12:02:53 »
Generovane ORM modely je treba schvalovat clovekem?

myslim situaci, kdy je vygenerujete jednou z legacy databaze a potom uz je edituje clovek. vetsinou nejak funguji out of box, ale DB metadata vetsinou neobsahuji vsechny potrebne informace, musi doplnit clovek.

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #109 kdy: 02. 12. 2021, 12:15:46 »
Generovane ORM modely je treba schvalovat clovekem?

myslim situaci, kdy je vygenerujete jednou z legacy databaze a potom uz je edituje clovek. vetsinou nejak funguji out of box, ale DB metadata vetsinou neobsahuji vsechny potrebne informace, musi doplnit clovek.

Mozna... to jsem, ale jeste nezazil, ze bych mel legacy DB a chtel nad ni stavet novy projekt pro ktery bych si z ni generoval model...
Asi bych se i v takovem pripade snazil o nejaky jiny pristup...


Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #110 kdy: 02. 12. 2021, 13:24:51 »
Mozna... to jsem, ale jeste nezazil, ze bych mel legacy DB a chtel nad ni stavet novy projekt pro ktery bych si z ni generoval model...

podle me docela casta situace.

Asi bych se i v takovem pripade snazil o nejaky jiny pristup...

jaky?

pokud chcete ORM, alternativni pristup je pouzit reflexi z metadat, a dopsat jen to co chcete navic. (co nejde odvodit). Coz se hodi u nejakych malych jednoucelovych veci.

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #111 kdy: 02. 12. 2021, 13:43:43 »
jinak podle me vetsina ORM reflexi bez explicitniho vygenerovani kodu ani neumoznuje. Ja to pouzivam v SQLAlchemy, ale treba v djangu nebo rails active record to AFAIK nejde.

BoneFlute

  • *****
  • 1 841
    • Zobrazit profil
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #112 kdy: 02. 12. 2021, 14:57:54 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného :)

Mel bys nejakej netrivialni priklad 2?

Inspiroval bych se co ostatní uváděli: mám verzovanou databázi. Změním tabulku, přejmenuju pár sloupců. schema-manage mi zařve, že je tam neverzovaná změna. Řeknu mu teda, aby vygeneroval sql-commit z té změny. Jenže jsem ty sloupce přejmenoval tak šikovně, že jsem ten nástroj zmátl, a on místo aby udělal příkaz pro přejmenování, tak udělá drop table + create table. Takže to předělám jak to má být, a commitnu.

Nebo z PHP světa, composer: nastavím si balíček, že má být ve verzi vendor/balicek:1.*, a on mi vygeneruje graf závislostí, kde bude jinejvendor/jinejbalicek:1.8.6, ale já vím, že zrovna tento má chybu, a potřebuju nižší/vyšší. Tak to poedituju/přinutím mu dát konkrétní verzi, a zase dám composerem zkontrolovat závislosti a vygenerovat graf.
« Poslední změna: 02. 12. 2021, 15:05:28 od BoneFlute »

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #113 kdy: 02. 12. 2021, 16:23:05 »
Mozna... to jsem, ale jeste nezazil, ze bych mel legacy DB a chtel nad ni stavet novy projekt pro ktery bych si z ni generoval model...

podle me docela casta situace.

Asi bych se i v takovem pripade snazil o nejaky jiny pristup...

jaky?

pokud chcete ORM, alternativni pristup je pouzit reflexi z metadat, a dopsat jen to co chcete navic. (co nejde odvodit). Coz se hodi u nejakych malych jednoucelovych veci.

Asi bych sel nejakou cestou podobnou jako treba u jaxb.
Zvlastni soubor s pravidly pro kustomizaci, ktery se pri generovani zpracuje vedle schematu a vygenerovany entity budou rovnou tak jak je chci....

Zalezelo by na konkretni situaci. Bez konkretniho prikladu co by tam bylo potreba menit nedokazu rict.

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #114 kdy: 02. 12. 2021, 16:40:20 »
Zalezelo by na konkretni situaci. Bez konkretniho prikladu co by tam bylo potreba menit nedokazu rict.

typicky vztahy, ktere nejdou vycist z cizich klicu.

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #115 kdy: 02. 12. 2021, 16:43:59 »
Inspiroval bych se co ostatní uváděli: mám verzovanou databázi. Změním tabulku, přejmenuju pár sloupců. schema-manage mi zařve, že je tam neverzovaná změna. Řeknu mu teda, aby vygeneroval sql-commit z té změny. Jenže jsem ty sloupce přejmenoval tak šikovně, že jsem ten nástroj zmátl, a on místo aby udělal příkaz pro přejmenování, tak udělá drop table + create table. Takže to předělám jak to má být, a commitnu.

S verzovanim DB schemat mam trochu problem... (kdyz neco verzuju tak predpokladam ze se snadno budu moct vratit k predchozi verzi ale to u DB a netrivialnich zmen "snadno" nejde) ale to je asi jedno.
V tomhle pripade je to stejne jedno.... co znamena ze "prejmenuju par sloupecku"
Pripojim se k DB a spustim nejaky "alter table" ne?

Takze jestli te spravne chapu tak si pustis nejakej kod nad DB, ten si neulozis protoze mas prece schema manage.
Ten ti ho vygeneruje spatne, takze to tam prepises aby to bylo tak jak uz si to jednou delal... a pak to commitnes.
Je to tak?
V tom pripade mi prijde jednodussi rovnou commitovat ty zmeny tak jak sem je psal predtim rucne a vynechat generator.

Nebo z PHP světa, composer: nastavím si balíček, že má být ve verzi vendor/balicek:1.*, a on mi vygeneruje graf závislostí, kde bude jinejvendor/jinejbalicek:1.8.6, ale já vím, že zrovna tento má chybu, a potřebuju nižší/vyšší. Tak to poedituju/přinutím mu dát konkrétní verzi, a zase dám composerem zkontrolovat závislosti a vygenerovat graf.

V php sem uz dloooouho nic nedelal takze si nejsem jistej v kramflecich, ten graf zavislosti je potreba commitovat?
Ale obcene bych nepovazoval konfiguraci dependency managementu za "kod".
Takze tam jsem OK s tim ze se kousek nejak generuje a kousek pise rucne.

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #116 kdy: 02. 12. 2021, 16:52:00 »
Zalezelo by na konkretni situaci. Bez konkretniho prikladu co by tam bylo potreba menit nedokazu rict.

typicky vztahy, ktere nejdou vycist z cizich klicu.

Jakoze mam sice sloupec s nejakejma IDckama z jiny tabule ale nemam nad tim definovany cizi klic?
No pak je otazka jestli chci, aby bylo to ORM chytrejsi nez sama databaze...
Nemit tam ten cizi klic muze mit nejakej duvod. A ja si pak spis myslim, ze je lepsi to ctit i v modelu.

Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #117 kdy: 02. 12. 2021, 17:05:53 »
Zalezelo by na konkretni situaci. Bez konkretniho prikladu co by tam bylo potreba menit nedokazu rict.

typicky vztahy, ktere nejdou vycist z cizich klicu.

Jakoze mam sice sloupec s nejakejma IDckama z jiny tabule ale nemam nad tim definovany cizi klic?
No pak je otazka jestli chci, aby bylo to ORM chytrejsi nez sama databaze...
Nemit tam ten cizi klic muze mit nejakej duvod. A ja si pak spis myslim, ze je lepsi to ctit i v modelu.

to je prave ten pripad, kdy chcete vygenerovany kod editovat rucne. Vygenerovane casti ale mohou byt i oddelene.

Zalezi, jestli v budoucnu hodlate generovat zmeny v DB podle aplikace, nebo naopak chcete synchronizovat podle DB, potom je editace vygenerovaneho kodu hloupost.
« Poslední změna: 02. 12. 2021, 17:08:26 od A.P.Hacker »

BoneFlute

  • *****
  • 1 841
    • Zobrazit profil
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #118 kdy: 02. 12. 2021, 17:32:33 »
Inspiroval bych se co ostatní uváděli: mám verzovanou databázi. Změním tabulku, přejmenuju pár sloupců. schema-manage mi zařve, že je tam neverzovaná změna. Řeknu mu teda, aby vygeneroval sql-commit z té změny. Jenže jsem ty sloupce přejmenoval tak šikovně, že jsem ten nástroj zmátl, a on místo aby udělal příkaz pro přejmenování, tak udělá drop table + create table. Takže to předělám jak to má být, a commitnu.

S verzovanim DB schemat mam trochu problem... (kdyz neco verzuju tak predpokladam ze se snadno budu moct vratit k predchozi verzi ale to u DB a netrivialnich zmen "snadno" nejde) ale to je asi jedno.
V tomhle pripade je to stejne jedno.... co znamena ze "prejmenuju par sloupecku"
Pripojim se k DB a spustim nejaky "alter table" ne?

Takze jestli te spravne chapu tak si pustis nejakej kod nad DB, ten si neulozis protoze mas prece schema manage.
Ten ti ho vygeneruje spatne, takze to tam prepises aby to bylo tak jak uz si to jednou delal... a pak to commitnes.
Je to tak?
V tom pripade mi prijde jednodussi rovnou commitovat ty zmeny tak jak sem je psal predtim rucne a vynechat generator.
Ono je to tak jak říkáš. A je to pravda, že by to bylo jednodužší, kdyby to lidi dělali. Ale oni to nedělají. Takže než poslouchat nadávky, to tam je ten generátor, a vysvětlit jim, že si to jen musí ještě zkontrolovat je reálnější.

Nebo z PHP světa, composer: nastavím si balíček, že má být ve verzi vendor/balicek:1.*, a on mi vygeneruje graf závislostí, kde bude jinejvendor/jinejbalicek:1.8.6, ale já vím, že zrovna tento má chybu, a potřebuju nižší/vyšší. Tak to poedituju/přinutím mu dát konkrétní verzi, a zase dám composerem zkontrolovat závislosti a vygenerovat graf.

V php sem uz dloooouho nic nedelal takze si nejsem jistej v kramflecich, ten graf zavislosti je potreba commitovat?
Ale obcene bych nepovazoval konfiguraci dependency managementu za "kod".
Takze tam jsem OK s tim ze se kousek nejak generuje a kousek pise rucne.
Ten graf závislostí je třeba commitovat (není to specifikum php, je to principielní problém), protože ty máš v jednom souboru uvedený cca verze a balíčky, které chceš, zatímco v tom druhém souboru jsou už přesné verze všech balíčků. Aby se pokaždé vygeneroval stejný graf a stáhly se vždycky ty samé balíčky - důsledky si asi domyslíš.

BoneFlute

  • *****
  • 1 841
    • Zobrazit profil
Re:Rust - std::ANY alebo lepší návrh?
« Odpověď #119 kdy: 02. 12. 2021, 17:43:03 »

Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.

Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)

TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného :)

Mel bys nejakej netrivialni priklad 2?

Příklad 3: VisualStudio má návrháře UI. Můžeš si tam naklikat, natahat, naarangovat elementy. Ty se potom zapíšou do souboru. Buď do C#, nebo do XAML. V případě XAML se tento ještě zpracovává do výsledného něčeho. C# je part třída, kde máš jednu část, kterou má na starost návrhář, a druhou část, kterou používáš ty jako vývojář pro vlastní opičárny. Když hrábneš do té návrhářské třídy, tak pokud to nepřeženeš, tak se to zpětně promítne do toho návrháře. Osvědčilo se mi do té návrhářské třídy koukat. Lépe si všimnu, že jsem udělal nějakou nepravost. Nebo naopak, při přejmenování nějakého elementu, se přejmenuje i tady a návrhář to v pohodě zkousne.