Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Kód: [Vybrat]A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
Jde o styl uvažování. Dneska, díky okolnostem, je ten způsob uvažování následující:
- vytáhni z persistence
- uprav
- ulož zpět do persistence
Což je naprosto umělé. A správně by to mělo být:
- najdi v poli [1] požadovaný záznam
- uprav v něm co potřebuješ
Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit
Transakce je v pohodě, o tom není řeč. Co považuji za umělé je to vytahování odněkud a pak to tam opět vracení.
1/ úplně obyčejném, nespeciálním, v žádném ORM nasledovaném
Typicky chci načíst objekt, nějak ho měnit, validovat a až nakonec naráz uložit.To je ta chyba v uvažování. Nechci ten objekt načíst, chci ho jen změnit.
Takže když změním instanci objektu z jednoho procesu, co uvidí druhý proces (co by sdílel stejný stav)? Uvidí hned změnu, sdílejí stejnou instanci?Uvidí změnněnou hodnotu toho objektu. Když změním třeba Person.name = "Jozef", uvidí taky "Jozef". Když přidám, nebo odeberu prvek z kolekce, přidá se či odebere i u toho druhého. (Případně ve všech ostatních.)
nějakému distribuovanému systému s mapováním, řešením verzí, kolizí, s attache a detached persistentním stavem atd., tedy vše co se řeší v SQL příp. ORM.Tak přesně takto to není. Vše, co jsi uvedl je problematika čistě toho našeho nám známého řešení. A ani náhodou to není univerzální problematika. Snad jedině řešení kolizí stojí za úvahu.
Ne, v praxi nesetkal.Kromě SmalltalkuSmalltalk určitě můžeme považovat za výjimku potvrzující pravidlo.
Jen pro pořádek, setkal jsi se s řešením více instancí jednoho image, tedy tak, aby sdíleli stejný stav, ideálně i napříč sítí?
To se taky moc nechytloNo a jsme u toho. Pro spoustu malých projektů by stačil přístup Smalltalku.Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí.
Logické jazyky ještě víc, tam je program DB + pravidlaZatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.Kromě Smalltalku
Co se tyce objektovych databazi tak podle me jsou docela rozsirene. Napr. kdyz delam mobilni appku a potrebuju nejakou persistenci objektu na strane klienta, tak sahnu po https://realm.io/.Já teda vidím, realm.io jako ORMko do MongoDB. Koukám se špatně?
Realm is a mobile database: a replacement for SQLite & ORMs
https://github.com/realm/realm-core
https://github.com/realm/realm-java
Tohle se necha pouzivat zadarmo a dal jsem nikdy nesel. To s tim MongoDB je ohledne sync. dat mezi clientem <> serverem a okolo toho maji postaveny biznis.
Java version of Realm currently runs only on Android
https://github.com/realm/realm-java
Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí.
Logické jazyky ještě víc, tam je program DB + pravidlaZatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.Kromě Smalltalku
Když si vezmu třeba něco takového: https://crates.io/crates/diesel, což je ještě implementace, která se mi líbí, tak jsem skončil u toho, že takto to dělat nechci. Není to správně OOP....a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze.Kdysi jsem se bavil s autorem db4objects (C. Rosenberger). Hlavní problém je v neflexibilnosti tzv. OO jazyků. On zápasil s Javou (a portem pro C#, pro ten si napsal transpiler z Javy), dnes by to pro Rust, Swift nebo Go bylo ještě horší.
že existují lidi, co se snaží kladivem zatlouct šroubky, a "ze své vlastní zkušenosti" pak šíří, jak jsou ty šroubky nesmyslná technologie.Jako profesně bývalej truhlář musím poznamenat, že šroubky se kladivem zatloukají naprosto v pohodě ;-)
Ondra:CitaceIMHO v dlouhodobějším horizontu pracnost+nákladovost srovnatelných technologií konvertuje k podobné hodnotě.Toto myslím není úplně přesně řečeno. Jsou jednoduché projekty, které se do tohoto stavu niky nedostanou a noSQL tam bude o něco rychlejší (o definici tabulek). A jsou projekty, které jsou tak složité, že když je někdo založí na jednoduchých technologiích, spláče nad vejdělkem.
Jak jsem se poprvé dozvěděl o MongoDB? Bylo to asi v roce 2016 a vedoucí projektu řekl "Na blbnutí s SQL nemáme čas!" Zákazník očekával rozběhnutí projektu prakticky hned. Než jsem si to osahal, myslel jsem si, že se zbláznil. Ale vývoj produktu - oproti jiným projektům - doslova uháněl. A to se zadání v průběhu projektu měnilo, jak se zákazník vyspal. S NoSQL se člověk nesoustředí na "vyšpekulování krutopřísného Joinu", ale hloubá nad svým objektem, aby lumpík dělal, co dělat má.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
