• Dragi članovi, prochitajte OVU vest u vezi nove teme!
  • Molimo vas sve da pročitate PRAVILA FORUMA i da se istih pridržavate.
  • Secret Level Discord server je LIVE! Za više informacija kliknite OVDE

Random/Free Discussion Thread

@Teoreticar letimicno sam preletio preko problema. Cini mi se kao klasicno igranje inzenjera, pristup tipican za ovu struku. Guid je sasvim solidno rijesenje i vjerovatno dovoljno dobro.

Davno u ranim guid implementacijama u .Netu sam imao masu kolizija u sistemima sa milionima transakcija na dnevnom nivou. Te biblioteke su implementirane u nekoliko iteracija tokom skoro 2 decenije i skoro da su bullet proof. Sansa za koliziju Guid u teoriji jeste suludo mala ali u praksi je drasticno veca (ali i pored toga beznacajna za razvoj).

Elem, otkad je guid zazivio sve je rijedja situacija za custom implementacijama identifikatora, bar je lakse ljudima objasniti nesto sto je vise/manje standard. Sjecam se vremena kad sam se borio sa ludacima koji su htjeli gapless autoincrement idjeve :D
 
@disturbed
Guid moze da ima kolizuju, ali isto tako ovo resenje moze da ima identican problem, cim ti nisi na neki nacin stavio unique constrain.

Sta ako imas bug bilo sa generatorom id-a na serveru ili u lokalu (ili sa kasom i slicno) i izdas n racuna sa istim PFR brojem? I dalje moras imati mehanizam da mozes da popravis to. Racun mora, pa mora da prodje kroz sistem.


Sjecam se vremena kad sam se borio sa ludacima koji su htjeli gapless autoincrement idjeve :D
Click to expand...
Da bi izgledalo lepo :D ili da bi postojao nacin za prev/next entitet?

Super je problem.

Trebalo mi je prev/next za Event Sourcing.
Ideja mi je bila da kad kreiram novi entitet ubacim u njega pored Guid Id-a, i IdNext i IdPrev, gde bi IdPrev bio null, a IdNext jos jedan generisan guid. I onda kad ubacujem sledeci entitet u red, da ubacim da Id bude IdPrev iz prethnodnog, IdNext da bude novi. Kad vadis IdNext koji ne postoji da to tretiras kao tumbstone.

E sad, posto je Event Sourcing i posto sansa za koliziju je po entitetu, a ne po celoj bazi, i posto u slucaju sa kojim sam radio, to je bila mala sansa mislim da je bilo dovoljno dobro. Ali, na kraju nisam hteo da komplikujem, koristio sam samo timestamp :) i izvlacio sve state-ove po Id-u.

Za sistem sa puno redova, gde ima vise sudaranja i paralelnih procesa, mislim da bi mogla jedna tabela da se samo ubacuju, bez da znas prev/next i da posle postoji proces, kad smo sigurni da je sve zavrseno od transakcija i ostalog, koji ce u drugu tabelu (ili eventualno update), u odnosu na timestamp da napravi prev/next i da vadis sve sa join-om (ili kako vec)


A bas gapless autoincrement - pa mislim da bi moglo u teoriji :D
Penal bi bio ogroman, cak i za single server, posto bi paralelizam bio limitiran na transakcije koje nemaju dodirne tacke u vidu tabela.

E sad da li bi mogao da odradis prelocate prvih n redova, tako sto ces rucno ubaciti samo id redom i nista vise u klasicnu (ACID) bazu, i onda na nivou softvera trazis prvo "lowest null" i da kad krenes da upisujes da se lockuje tabela. Ako krenes paralelno ako postoji Optimistic Concurrency Control - i pukne upit, odradis retry na nivou software-a? Nisam bas siguran da ce ovo da radi? Penal bi isto velik, mada ne koliko bez paralelizma, ali ne bi bio garantovan order, posto ti transakcija i dalje moze puci.
 
Last edited:
@Teoreticar imam osjecaj da spamujemo spam temu :D

prev/next u ES zvuci kao ozbiljan design smell, isto tako ne razumijem kakve entity veze ima sa ES. Mozda mislis na event record u event storeu? I u tom slucaju ne vidim zasto bi imao ulancanu listu. Ako vec ne mozes da se pouzdas u atomicnost cuvanja evenata onda mozes da imas neki sequence na osnovu kojeg radis replay. Opet, ko zna kakav je tvoj kontekst bio i vjerujem da su razlozi bili validni ali generalno takve stvari komplikuju design a ne dobija se puno na vrijednosti. U takvim slucajevima rijesenje nije iskljucivo na tehnickom timu vec bi svi trebali "back to the drawing board" i raspravljati sa product/business strane i koliko tako nesto zaista utice na bounded context. Inace, jezim se kad devovi sami odlucuju da li ce nesto biti (micro)servis ili ne, ali to je druga prica.

Za gapless autoincrement je bilo jako davno ali sjecam se da sam napisao rjesenje ali nikad im nisam rekao jer je zahtjev bio retardiran od samog starta (a pretpostavljam i moje rjesenje tada).
 
@disturbed
Pod entitet u ES mislim na npr User-a, Order ili sta ima smisla biznisu, koji se sastoji od n state-changinge event-ova. Postoji m entiteta.
ES zbog same forme skladistenja podataka dolazi sa auditing-om. A, ovde je bila ideja da se implementira Undo/Redo, ili bar da user moze da na 2 komande (prev/next) da vidi kako se entitet menjao vremenom. Implementacija nije bila problem, a marketing je mogao pricu oko toga da napravi.

Inace, jezim se kad devovi sami odlucuju da li ce nesto biti (micro)servis ili ne, ali to je druga prica.
Click to expand...

Pa, nemoj tako... moze PO da odluci da se izdvoji deo bounded context-a u posebnu aplikaciju - "mikroservis", koja ce delom zvati istu bazu, delom pozivati API aplikacije i delom imati svoj storage.
 
Jbg,nisam otvarao. U ovima koja su cela nalaze se fetusi pilica.
Ne vidim zasto bih otvarao,ako prodaju jaja onda unutra treba da su ispravna jaja. Sta ja tu mogu da proverim ustvari.
 
Nikola22 said:
Jaja iz Lidla danas,vredi li ovo negde prijaviti? Imam fiskalni it'd.... ili bolje da nastavim da gledam svoja posla. 😀
View attachment 12421
Click to expand...
Jaja se uvek proveravaju kre kupovine bez obzira odakle kupuješ. Meni su omiljeni ovi iz Koka-mar gde bukvalno pregledaju sami sva jaja pre nego što ti daju. Jaja pucaju u tansportu (što možeš da proveriš), raziju embrio u period od provere do prodaje (za šta bi mirao da ih gledaš ka izvoru svetla. Videćeš povremeno ljude da i to rade) itd.

Sa druge strane sećam se da su nekada jaja trpali u fišeke od novina i da u ogromnoj većini slučajeva nisu pucala. Danas popucaju u ovim zaštitnim korpama. Nešto se tu promenilo.
 
CARNEX said:
Jaja se uvek proveravaju kre kupovine bez obzira odakle kupuješ. Meni su omiljeni ovi iz Koka-mar gde bukvalno pregledaju sami sva jaja pre nego što ti daju. Jaja pucaju u tansportu (što možeš da proveriš), raziju embrio u period od provere do prodaje (za šta bi mirao da ih gledaš ka izvoru svetla. Videćeš povremeno ljude da i to rade) itd.

Sa druge strane sećam se da su nekada jaja trpali u fišeke od novina i da u ogromnoj većini slučajeva nisu pucala. Danas popucaju u ovim zaštitnim korpama. Nešto se tu promenilo.
Click to expand...
Ishrana kokoski je drugačija, seoske kokoške što šetaju okolo imaju mnogo deblju ljusku jaja
 
Nikola22 said:
Jaja iz Lidla danas,vredi li ovo negde prijaviti? Imam fiskalni it'd.... ili bolje da nastavim da gledam svoja posla. 😀
Click to expand...

Ja sam par puta nesto reklamirao u Lidlu i uvek je bilo extra iskustvo, dali bi mi vaucer koji je vredio i mnogo vise nego ono sto sam platio.

disturbed said:
Razlika izmedju ovog i domaceg jajeta je nebo i zemlja. Prvi ja sam bio skeptican, ali sad kad moram da kupim jaja u marketu dusa me boli.
Click to expand...

O da, ne moze da se poredi... ko nije probao prava domaca jaja (i sir, mleko), taj nije ziveo.
 
You must log in or register to reply here.
Back
Top Bottom