Igen, az teljesen életszerű, hogy hálózat nélkül futtatod a javascript alkalmazásodat.

#17296sztanozs
Az ökoszisztémát érintő problémák általában fejlesztés közben jönnek elő, pl. 1 napig turkálod, hogy az npm install most miért dob hibát és korábban miért volt jó. És ezt az 1 napot valaki neked kifizeti, aki ha tudná, nem örülne. A maradék probléma meg leginkább élesben, pl. memory leak-ek.

UAT arra van, hogy az ügyfél átvegye és jóváhagyja azt, amit fejlesztettél. Ha itt derülnek ki hibák, akkor valamit rosszul csináltok.

Nem nullat azert. Te is tudod, h a security az tobbretegu tortenet; egy megfeleloen korlatozott kontenerbol kitorni nem egyszeru. (Vagy gondolom nem azt allitod, hogy a Linux kernel capability korlatai nem szamitanak.)

while (!sleep) sheep++;

UAT alatt nagy vonalakban értettem a tesztelést. Amúgy ha nincs security vagy eovs miatt update akkor általában ezek nem is változnak funkcióváltozás nélkül.
Ha meg változik a funkció (és a fejlesztő frissíti a komponenseket), akkor ez nálunk is csak
- először fejlesztői, majd tesztkörnyezeten történhet (és csak sikeres tesztelés után mehet élesbe)
- teszt és éles környezetbe csak auditált repóból jöhet a dependencia

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

A web-el kapcsolatban én(mint általában user) csak 1 előnyt tudok "felsorolni". Mégpedig azt, hogy hasznos funkciók vannak benne. Az összes többi csak hátrány:
1.: Lassú
2.: Van, hogy nem működik
3.: Nem biztonságos. Ha 1 gép rá csatlakozik a hálózatra, onnantól kezdve feltörhető(legalábbis, ha hasznos funkciója van). Arról nem is beszélve, hogy mindig akadnak okosabbak, mint a webfejlesztők(lásd pl. itt. Gyakorlatilag csak azt nem törik fel egyesek, amit nem akarnak. Az más kérdés, hogy ezt nyom nélkül nem tudják megtenni(mindennek nyoma van). Csak van, hogy nagyon sokáig tartana a "nyomozás".

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Szerintem csak nem olvastál ennek eléggé utána.
1. Mihez képest lassú - egy elosztott hálózat sokkal gyorsabb tud lenni, mint egy gép
2. Van hogy a gép sem működik. Több gép nagyobb valószínűséggel működik, mint egy. Természetesen be lehet építeni egyéb redundanciákat is (pl. több különálló hálózati kapcsolat). Az elmúlt 10-15 év tapasztalata alapján többet volt elérhetetlen az otthoni gépem frissítés vagy hardver hiba miatt, mint a működő internet hiánya miatt.
3. Alkalmazásfejlesztésnél alap a többrétegű architektúra, ami nem csökkenti, hanem növeli a biztonságot. Minél távolabb van az üzleti logika a felhasználótól (minél több rétegen keresztül elérhető), annál biztonságosabb. Ráadásul a fizikailag kompromittált gépek hálózat nélkül is elérhetők, és azokból később adat kinyerhető (vannak nagyon izgalmas side-channel technikák).

[ Szerkesztve ]

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Egyik sem a web hibája, amiket írsz. A mai világban jellemzően soha semmire nincs se idő, se pénz, se hozzáértés, egy lerágott csontot akarnak még tovább rágni, és hús már nincs rajta, szóval a csont törik el. Kb az a szoftverfejlesztés jelene. Minden, amit fejlesztenek, biztonságtechnikában lukacsosabb, mint az ementáli sajtok. De az nem a web hibája. A bináris alkalmazások ugyan úgy hulladékok.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

EF, migrations, indexelés. Google példák alapján nem találtam rá megoldást.

Vannak táblákat reprezentáló osztályaim, közöttük egy-egy relációk, az osztályokban 3-4 ilyesmi:

public TablaEgyik TablaEgyik { get; set; } = new TablaEgyik();
public TablaMasik TablaMasik { get; set; } = new TablaMasik();
public TablaHarmadik TablaHarmadik { get; set; } = new TablaHarmadik();

(TablaEgyik, TablaMasik és TablaHarmadik mind létező osztályok.)

Az id-k összekapcsolása automatikusan megvan (ellenőriztem a kimenetben), de az indexelés csak egyesével van meg. Például van TablaEgyik, TablaMasik, TablaHarmadik táblám hozzákötve az EntityEgyik-hez. Az EntityEgyik-nek lesz külön oszlopa, ami a TablaEgyik kulcsához tárol értéket, meg lesz rá indexelés az EntityEgyik-ben, ami 3 külön kapcsolat esetén 3 külön index. Ilyesmi extra oszlopokat hoz létre: TablaEgyikId, TablaMasikId, TablaHarmadikId, és egyesével indexeket készít rájuk. De az jellegében Index1, és Index2, és Index3, és nem Index1 + Index2 + Index3. Kellene nekem összesített index is. Amikor megpróbálok valami ilyesmit:

modelBuilder.Entity<EntityEgyik>()
.HasKey(c => new { c.TablaEgyik, c.TablaMasik, c.TablaHarmadik });

akkor azt kapom, hogy a TablaEgyik, TablaMasik, TablaHarmadik a db motor által nem támogatott típusok. A migrations-nek nem tudom megmondani, hogy a TablaEgyik, TablaMasik és TablaHarmadik mögött automatikusan beillesztett változókra ( TablaEgyikId, TablaMasikId, TablaHarmadikId ) készítsen kompozitot.

Létezik bármi trükk rá? Vagy fel kell adnom a kényelmet + fejlesztési szabadságfokot, explicite gyártanom le nekem azokat a kulcs mezőket, plusz utána "kézileg" kell megadnom a kapcsolatokat?

Nem lenne rossz, ha az explicit megadásokat megúszhatnám, mert azzal együtt minden kényelem is odavan, ami miatt egyáltalán a migrations-t (és az EF-et) érdemes használni.

Bármilyen ötletnek, olvasni való blognak / linknek örülnék.

(És bocsi a szerkesztés hiányáért. A régi szerkesztő egy kekec bughalmaz, az új szerkesztő meg egy trágya, nem tudom kiemelni a kódrészleteket kényelmesen.)

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Én a helyedben a hivatalos doksival kezdeném: Indexes - EF Core | Microsoft Docs
Szívesen!

Én kérek elnézést!

Egyetértek Veled, és köszönöm a pontosítást.

#17305 sztanozs:
Tényleg nem olvastam utána. De ez az én feladatom lenne, vagy a Samsung Nvidia stb... fejlesztőinek(biztonsági szakembereinek) feladata lenne? Biztos vagyok benne, hogy az utóbbiaknak kellene/kellett volna... Másrészt meg a 16-17 éves tinik(!) törik fel azokat a rendszereket, amiket állítolag magasan kvalifikált, felnőtt "szakemberek" alkottak. Úgy látszik, hogy a tinik jobban utánaolvastak náluk(vagy többet/jobban használták a szürkeállományukat).
1.: Ahhoz képest lassú, mint amit a HW indokoltá tesz.
2.: Igen, van úgy. De nem 1 példát tudnék hozni a rendszer lassúságára. Pl. amikor a boltban kb. 1 percig(!) "gondolkodik" kártyaolvasás után, majd a végén kiköp valamit(van úgy, hogy végül is elfogadja a tranzakciót, de van úgy, hogy nem). Vagy EÜ. szakrendelésen sorszám kérésnél a hölgyek azt mondják, hogy lassú a rendszer, és erre várunk. Vagy a patikában... stb... stb... stb...
3.: "Minél távolabb van az üzleti logika a felhasználótól (minél több rétegen keresztül elérhető), annál biztonságosabb." -> De csak biztonságosabb, és nem biztonságos. Nagy különbség! Valamint lásd, amit fentebb a tinik esetéről írtam.

De végül is coco2 jól összefoglalta a dolgot.

[ Szerkesztve ]

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Azt hiszem, hogy most végre sikerült megértenem az optimalizálás fontosságát. Ha minden programozó atoi-t optimalizálna reggeltől estig, akkor nem maradna ideje egyéb fejlesztésre, így nem készülnének sérülékeny szoftverek sem, mert nem készülnének szoftverek sem.

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Kifejlesztik az asp csodát az azúrra, és alá raknak egyetlen cpu magot a napi 135ezer felhasználónak, mert a többi pénzt valaki zsebre rakta. Nem lassabb az, mint amit a HW indokolttá tesz

Én is törtem fel 16-17 éves tiniként hálót. Akkor még "Novell Network"-nek hívták (a 3.11-es működött akkoriban a suliban), szóval szerintem van arra rálátásom, hogyan megy. Temérdek sok időm volt a meglévő doksikat olvasni, és kiszemeltem a leggyengébb pontot, amit emberi hiszékenység + tévedés + egy nagyon szégyentelen hazugsággal keresztül lehet törni. És elkövettem. Nem azért, hogy büszke legyek rá, hanem az izgalomért Hogy egy egész évnyi erőfeszítésem ment rá egyetlen akcióra, az meg olyasmi, hogy időmilliomos voltam valódi kihívás nélkül, suli halál unalom, csajok frigidek, szóval a suli hálózatának biztonsága lett játékszer. Azóta a technológia fejlődött, de a társadalom nem. A suli még mindig halál unalom, a csajok még mindig frigidek, a fiatalok még mindig időmilliomosok valós kihívások nélkül. Én azt mondanám, a helyzet azóta is változatlan.

@martonx:
Azóta megnéztem pár oktató videót, és mindenütt belepakoltak explicite extra mezőket, amikre az indexet rárakták. A jelek szerint indexeket virtuálisan leírni, és később azokra hivatkozni az EF még nem tud. Beletörődtem.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

"A jelek szerint indexeket virtuálisan leírni, és később azokra hivatkozni az EF még nem tud" -

azóta is ezen gondolkozok: tényleg számít ez? Van 3 meződ, és mindegyiken van 1-1 index. Vagy van ugyanez a 3 meződ, és 1 komplex index van a három felett? Komolyan kérdezem, benchmarkot is megnéznék, hogy a valóságban mi a különbség a két megoldás között.
Mert én azt tippelem, hogy szinte semmi, bár lehet, hogy sok milliárd adatsornál már a szinte semmikre is van értelme optimalizálni, bár ott meg már úgysem ORM-ezik senki.

Én kérek elnézést!

Nekem az a tippem, hogy ha 3 felindexelt oszlopra ráraksz egy kompozit indexet, az inkább rontani fog a teljesítményen.
Az írási teljesítményt garantáltan rontja, és olvasásnál szerintem nem hoz kb. semmit.

A leggyengébb láncszem mindig is a humán tényező lesz, lehet akármilyen csilivili biztonság, manapság nem úgy törik a rendszereket, hogy fogják a kalapácsot, azt hajrá, elég kiküldeni egy tonna emialt, az egyik hülye úgy is rákattint a linkre, vagy megadja a jelszavát.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Én már rég nem lepődök meg semmin, ilyet meg se akarok tippelni. Az biztos, hogy az egy szál kompozit index folyton buzerálva lesz, bármelyik oszlopban is változzon bármi, azaz íráskor vélhetően az 1 nagy kompozit index rosszabb lesz (aztán lehet, hogy ez is hibahatáron belül mérhetetlen eltérés csak). A külön külön index-ek meg lehet, hogy olvasáskor teljesítenek valamivel rosszabbul, de erre se vennék mérget. Ezért is kérdeztem a kollégát, hogy ha már ennyire szenved, hogy mindenáron egy nagy kompozit indexet akar, valóban kimérte, és drasztikusan jobb teljesítményt ad a kompozit index?
Szóval belőlem pusztán a szakmai kíváncsiság beszélt, mivel ott van a DB-je, remélhetőleg több millió adatsorokkal, könnyedén ki tudja mérni a különbséget a kétféle indexelési stratégia között.

Én kérek elnézést!

Szerintem a lekérdezés módjától (vagy módjaitól) és gyakoriságától függ, hogy hogyan érdemes indexelni. Ha ugyarra a 3 oszlopra szűrsz mindig, akkor kompozit, mert egy selecten belül, egy táblán csak egy indexet fog használni.

Nyílván a saját use caseben ő tudja kimérni (esetleg query plannerrel).

Mondjuk én nem nagyon értem, hogy miért kell az indexeket is EF-fel generálni/generáltatni. Lehet írni hozzá custom migrációt is és akkor létrehozod kézzel.

Csak ezekben az esetekben azok, akiket lehülyézel, ők a Samsung-nál, Nvidia-nál stb... jelszóval rendelkező emberkék. Szóval akkor vagy mégsem olyan kvalifikáltak, vagy nem tudom... Meg a tiniknek amúgy is tudni kellene, hogy kiknek kell email-t küldeni, ráadásul még a munkahelyüket is...

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Nem értem most miről írsz. Ezt írtad: "vagy mit matat a filesystemben". Hát ha dockerből futtatod akkor pontosan azt amit megengedsz neki.

Ha pedig dockerből futtatod akkor általában egy tűzfal mögött van. Akkor meg pontosan annyira kontrollált a környezet amennyire Te akarod.

Vagy most mit forgatunk ki a mondandómból?

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Vagy EÜ. szakrendelésen sorszám kérésnél a hölgyek azt mondják, hogy lassú a rendszer, és erre várunk. Vagy a patikában...
Ezek mondjuk nem webes gépek, de tény, hogy a hálózati kommunikációt nem volna nagy truváj rendesen összedobni, de általában ez sem sikerül (konkurencia kezelés).

De csak biztonságosabb, és nem biztonságos. Nagy különbség! Valamint lásd, amit fentebb a tinik esetéről írtam. Az iráni uránfinomítókat is megtörték, pedig azok konkrétan semmilyen külső hálózatra nem voltak kötve. Az ember a leggyengébb lántszem legtöbbször, nem a gép, ez be kell látni. A 16 éves hackerek sem a gépet törték fel, ahnem a felhasználót (password reuse és phishing)...
Persze tény az is, hogy a hanyag programozó mindegy mit programoz, lokális kódot, vagy webes kódot, az eredmény így is úgy is sz@r lesz.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Az ember ember, mindegy hol dolgozik. Attól még lehet valaki jó a szakmájában, mert nem biztonsági szakember.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Az a tábla jelenleg 3 másik (a létszámuk később bővülni fog) tábla 1-1 sorához ad többlet információt azon a 3 dimenzión együttesen, és annak okán abban a táblában arra a 3 másik táblára foreign key van (a primary key / ID van bejegyezve). A szitu a sima indexekkel annyi, hogy azokat az EF automatán gyártotta, mert azt mondja, szerinte jók lesznek még valamire. Leszámítva a nagyon barkácsolást, fogalmam sincs, hogyan mondjam meg a migrations-nek, hogy ugyan ne gyártsa már le azokat az indexeket. Szóval ráhagytam. Ami a gyakorlatban tényleg jó lesz valamire, az a kompozit index, mert amikor abban a táblában keresni akarok, mind a 3 értéket tudni fogom. Apropó az az index igazából kompozit key, de nincs annotation support (én nem találtam) kompozit key-t felvenni a primary key mellé, míg index-re van annotation support - szóval index-ként lett kategorizálva. Hát, egy kicsit még szoknom kell a migrations rigolyáit. Lenne egy jó öreg lamp + phpmyadmin-om, nem lennének vele ilyen gondjaim, de most rám olvasták, hogy ezt kell szeretnem. Ennyi az összes nagy titok, nincs itt semmi misztérium, és végleg nem szakmai precizitáshoz van bármi köze a történetnek.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

de nincs annotation support (én nem találtam) kompozit key-t felvenni a primary key mellé, míg index-re van annotation support - szóval index-ként lett kategorizálva

Már az EF6 is tudott kompozit kulcsot attribútumon keresztül, úgyhogy kétlem, hogy ez igaz lenne.

[link]

Order property (EF6).

Ha jól látom, akkor EF Core alatt pedig a classra kell rakni az attribútumot, ebből szerintem lehet többet is:
[link]

De ugyanígy fluent apival a modelbuilderen keresztül is lehet, nem muszáj attribútumot/annotációt használni.

Ahogy a kapcsolótáblákat is lehet a modelbuilderen keresztül indexelni és akkor kompozit primary key lesz rajta.

[ Szerkesztve ]

Nem kellene, hogy minden programozó reggeltől estig az atoi-t(itoa-t) optimalizálja. De pl. az alap STL függvények optimalizálására eddig is több évtized állt rendelkezésre. Én mindenesetre büszke vagyok, hogy sikerült optimalizálnom, annak ellenére, hogy tisztában vagyok azzal, hogy ezzel nem váltottam meg a világot. De nagyon könnyű lebecsülni a szerepét. Főleg utólag. Nézzük, hogy mobal(tudomásom szerint az egyetlen, aki felvállalta magát, valamint több régi projektjét is megosztotta a nyilvánossággal) itt ezt írta:

>Vergődhetünk még itt de az atoi implementációnál 99%, hogy nem csinálsz jobbat

Nos, az 1% jött be. Én sem tudtam biztosan, hogy meg tudom csinálni, de nem adtam fel. És kovisoft konstruktív kritikáinak a segítségével végül is sikerült. De ezzel rámutattam arra is, hogy az STL függvények nem kőbe vésett, szent és sérthetetlenek. Legalábbis nem lenne szabad, hogy így tekintsünk rájuk. Jobb lenne, ha az STL függvényeit nem lehetne 90% futásidő alá optimalizálni. De ez az optimalizálás sem jelentené azt, hogy nem készülnének szoftverek. Mert az STL optimalizálásával csak pár (rendszer) programozót kötne le. A programozók több mint 99%-a nem ezzel foglalkozik/foglalkozna.
Egyébként én jobban örülnék, ha ez a "közösség"(ahogy sztanozs nevez titeket) több ilyen diskurzus eredményeképpen létrehozna új dolgokat. Olyanokat, ami szerintetek nem 120-ad rangú téma. Mert a kovisoft-al való diskurzusunk következtében létrejött 1 új dolog(produktum). És az általatok létrehozott(fontosabb témában alkotott) új produktumokat tudná alkalmazni más olvasó is. De sajnos a ti "közösségetek"(is) kódolási impotenciában szenved. Nemhogy új produktumot tudna létrehozni(nem 120-ad rangú témában).
Egy másik aspektusa a dolognak meg az, hogy ugyan szívesen emlegetitek az én atoi optimalizálásomat lekicsinylően, de pl. a Cutter programomat nem reklámozzátok így(a többi produktumomról nem is beszélve). Szóval jó lenne, ha ez az állítolagos "közösség" megmutatná, hogy nem csak rizsázni tud, hanem képes lenne vmi. új megalkotására. Ha ezt látnám, akkor hidd el, hogy nem hátráltatnám a "közösség" munkáját.

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Igen, ef core, és attribútum lenne jobb (ebben az alkalmazásfejlesztési stílusban áttekinthetőbb, ha helyileg ott van, ahol az osztályt leírom). Primary key automatán van az "Id" név miatt. Amellé raktam még +1 kompozit indexet. Constraints nincs mellé. Talán kicsit biztonságosabb lenne azzal együtt.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Azért ha kérhetem ne magyarázzuk félre a dolgokat. Az első implementációval is jöttél, hogy mekkora ász vagy és kiderült, hogy korántsem működik úgy ahogy a régi, az általad lassúnak titulált implementáció.

Ezt most valahogy kifelejtetted a mondanivalódból és teljesen más kontextust teremtettél, de a lényeg megmaradt, hogy azt állítottam, hogy nem sikerül de te csakazértismegcsináltad.

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Persze, hogy jobban tetszik ha nem állítasz valótlan dolgokat. Ahogy korábban is most is fejezzük be mert megint kezded a szokásos játékod.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Ne haragudj, nem hiszem, hogy a fejlesztőként dolgozó, itt fórumozó arcok kódolási impotenciában szenvednének, hiszen valószínűleg (legalább is részben) ezért kapják a fizetésüket. Persze nem mindenki él meg ebből itt, de úgy vélem többen vannak, mint azt gondolod. Másrészt ez nem a C topik, hogy itt mindenki C programot optimalizáljon, ez egy általános programozási fórum, ahol gyakorlatilag megtalálsz mindenkit a C-től a VB6 programozóig; ráadásul a programok nagy része nem a nagy nyilvánosságnak készül, hogy valami honlapon (vagy a github publikus repójában fent legyen) - ezek hiányából ne vonj le túl mély következtetést.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

A (nem csak itt) fórumozó arcokról, és főleg a fórum(ok) szerepéről úgy általában más a véleményünk.
Arról, hogy ez nem C topik, az engem nem zavar. itt van pl . egy Vb.Net-es és 1 C# kódom is. Mivel nem törölték, ezért gondolom, hogy nyugodtan elférnek egymás mellett a C, Vb6, Vba, Vb.Net, C# meg mit'tomén milyen kódok is. De a C(vagy egyéb) topikokban sem látok túl sok kódot). Másrészt (főleg algoritmusos, de egyéb probléma esetén is) szóba jöhet(ne) a pszeudo kód is. Szóval a nyelv nem akadály!

Egyébként a ti "közösségetek" mit tart értéknek? Mik a prioritásai? Mi a (szakmai) fórumról alkotott egységes véleménye? Mert az én véleményem ismerhetitek egyrészt innen, másrészt a webhelyemről - de szívesen összesítem itt is, ha kérnétek. A ti álláspontotokkal azonban nem vagyok tisztában. Így kívülről úgy látszik, hogy a fő irányvonalatok csak a rizsa(de meg lehet cáfolni, ha tudjátok).

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

> Egyébként a ti "közösségetek" mit tart értékne

A kozossegrol nem tudok nyilatkozni, de nekem pl. ertek az, ha masoknak (vasarlo, ugyfel, munkaltato, vagy akarcsak egy kozosseg vagy szemely) valamifele erteket tudok adni. Ennek egyebkent az egyik fo indikatora (for-profit kornyezetben), ha fizetnek erte.

while (!sleep) sheep++;

elég kiküldeni egy tonna emialt, az egyik hülye úgy is rákattint a linkre, vagy megadja a jelszavát.

Minek emiallal (sic ) szorakozni, amikor "hulyek" tomkelege a bongeszoben tarolja az osszes jelszavat, 'oszt csodalkozik, amikor a virtualis coinjaik egyszerre csak atutalasra kerultek mashova, es attol kezdve eselye sincs panaszkodni se sehol?

[ Szerkesztve ]

Ma kell megtenni a tegnap eltervezetteket.

Arról nem is beszélve, amikor a "hülye" programozók cookie-ben tárolnak jelszót!

http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php

Hát aki olyan hülye, hogy virtuális coinokba rakja a pénzét, meg is érdemli.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

C# + Asp + EF core, kérdés tábla kapcsolatok kezelésére (a webapi miatt van probléma):

Vannak olyan tábláim mint:

Egyik {
public int Id;
public List<Masik> Masikk; }

Masik {
public int Id;
public List<Egyik> Egyikk; }

Aztán kész a kontroller, app indít, swagger, post add, és kapok vissza egy ilyesmi hibaüzenetet:

"The JSON value could not be converted to api.Entities.Egyik. Path: $.Masikk[0].Egyikk[0] | LineNumber: ** | BytePositionInLine: **."

Amivel kicsit vakarom a buksit, hogy leírtam EF-nek sok-sok kapcsolatokat, oda-vissza kapcsolgatnék, és amikor weben adat létrehozásnál le kell írni ilyesmit, akkor a sok-sok kapcsolat miatt vagy körbeérősen végtelen lett a szitu, vagy azt mondja a webapi, hogy bocsi, nem tudok validálni.

Valami olyasmi kellene, hogy a tábla referenciákra ha kap értéket, parsingolja be, ami jelen van, de ne legyen megkövetelve semmi. Vagy bármi könnyen kezelhető megoldás - javaslatoknak örülnék.

Van rá valami kitalált okosság?

[ Szerkesztve ]

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Öööö ez a két tábla közötti kapcsolat így biztos jó???

Jól látod, a hibaüzenetet azért kapod, mert ezzel az elrontott tábla kapcsolattal seperc alatt körkörös referenciát érsz el

Feltételezem latest .Net 6-ot használsz, feltételezem default System.Text.Json-nal szerializálsz. Ez esetben itt van némi olvasnivaló, benne talán megoldással is a problémádra: System.Text.Json features in .NET 6 (okyrylchuk.dev)

Én kérek elnézést!

A migrations azt csinálja, hogy ilyenkor gyárt egy harmadik táblát kapcsoló táblának, kb ilyesmit:

EgyikMasik {
public int EgyikId;
public int MasikId; }

és abba a táblába vési fel a rekordokat, hogy milyen összerendelések léteznek. A migrations kimenetet megnéztem, a köztes tábla létezik. És sajnos nem hiszem, hogy a sok-sok tábla kapcsolatot el lehetne kerülni. Alapvető igény egy adatbázisban.

A linket köszönöm, elkezdem majd olvasgatni.

Addig annyit tettem, hogy átállítottam nullable-re az összes változót, így a parser nem siránkozik. A db felírásokat is megcsinálja, csak sajnos a rekordok felírása után elszáll körkörös hivatkozással. Pislogok, hogy mi van. Megcsinálta, ott vannak a rekordok, miért kell kilépés helyett crashelnie?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Elolvastam a blogot, a linket köszönöm, sajnos nem sokat segít jelen helyzetben.

Szóval az entity-kben nullable-re raktam mindent, a bemeneti parser már nem sír. Megoldás gyanánt a bemeneti mezőkben a körkörös hivatkozást előidéző mezőket simán nem rakom bele. A funkció lefut, adatbázisban van a végeredmény, és akkor jön a meglepetés. Ez a sor crash-el:

return Ok(result);

A "result"-ban egy DbSet<Entity> van. A legfelső szinten ott vannak a tábla saját adatai, de az Entity-nek része a másik táblára hivatkozás, amiből tovább van hivatkozás, és úgy tovább - na azt az ASP kimeneti json parsere nem tudja lekezelni.

Valami olyasmi kellene, hogy megmondhassam a DbSet<Entity>-nek, hogy recursive depth: 0. Ami osztály, azt hagyja null-on.

Átmenetileg megfixeltem: kézileg explicite null-ra állítom az összes referenciát a kimenetben. A result json-ban ott rondálkodik egy null. Így legalább nem száll el. De szépnek éppen nem szép. Egyáltalán nem kellene feltüntetni osztályokat a kimenetben.

Lévén az ASP web controllerének beépített kódjáról van szó, nem vagyok benne biztos, hogy abba én belenyúlhatok kézileg

Bármi bölcsesség?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Melyik?

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Az agilis elveknek semmi köze a sebességhez. Kockazatmenedzsment módszer.

while (!sleep) sheep++;

Egy korlátos emberi erőforrás környezetben a többlet adminisztrációs teher fejlesztési időt von el. És még csak nem is dokumentálásra, hanem bürokráciára. De igazad van, a sebesség egy teljesen mellékes kérdés, elvégre nem is az alapból képtelen határidők mindig a baj. Szóval a szakmai oldalt nyugodtan félretehetjük - elvégre ki a fenét érdekel az - és lássuk az üzleti oldalát.

Az üzleti oldalon szakmailag hozzá nem értő emberek eggyeznek meg valami képtelenségben, amit a "körülmények összessége folytán realizálható objektivitás"-nak neveznek, miközben a buksija mélyén mindegyik azt gondolja, hogy majd pont a másikon fog csattanni az ostor az egyezményesen elkövetett hazugságok miatt. Ugyan mi is tudhat lehetségesen félresikerülni, ugye?

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Te még vagy nem dolgoztál agilisan vagy alkalmatlan vagy rá (no offense, de sokan vannak így). Az agilitás lényege, hogy a piac igényeire tudj gyorsan reagálni, és ne 5 év múlva kerüljön elő egy olyan feature ami most trendi. Amit felsoroltál problémát az agilitástól függetlenül is az lenne.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

A burokracia tultolasa az agilis fejlesztes felreertese.

Az agilis fejlesztesnek annyi a lenyege, hogy beismerjuk, hogy nem tudjuk pontosan felmerni a vegleges kovetelmenyeket, tehat elindulunk valamerre, es kozben folyamatosan csekkoljuk, hogy jo iranyba haladunk-e.

Az agilis fejlesztes eleve nem fer ossze a fix hataridokkel. Eleve a fix hatarido es a fix szkop nem fer ossze (vagy az egyik, vagy a masik). Tehat agilis fejlesztesnel nem tudunk elore megegyezni abban, hogy mikorra lesz kesz az egesz, hiszen pont azt ismerjuk be, hogy nem tudjuk meg, hogy mit fog tartalmazni a vegleges termek.

while (!sleep) sheep++;

>vagy alkalmatlan vagy rá (no offense..
None taken. Minden játéknak több oldala van. Ha valaki nyerni akar az egyiken, valaki másnak veszítenie kell hozzá a másikon. Én elég gyakran a vesztesek oldalán vagyok. Én legalább megbírom. Amilyen harmatos népek érkeznek ma az informatikába, ők valószínűleg alkalmatlanok lennének rá.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Na mindazokat magyarázd azoknak a főnököknek akiknek ha olyat mondasz, nem tudod előre felmérni és garantálni, hogy mennyi idő lesz az, amit el sem tudnak neked mondani, mert annyira kiforratlan és ködös az alapgondolat, azonnal látod rajtuk, hogy a következő pillanatban üvölteni kezdenének. És persze faképnél lehet őket hagyni, de hát pénzt locsolnak az informatikába, és szerintem cserébe jár nekik az idő, hogy tanuljanak, amennyire a cérnájuk bírja, bármennyi is legyen az.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។