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.


Příspěvky - BoneFlute

Stran: 1 [2] 3 4 ... 110
16
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 02:10:30 »
Vytvoření kopie range řešení není, když ten objekt už bude menší.
hluboké kopie

Každopádně tento problém má řekl bych celkem snadné řešení. Pokud se tedy bavíme o těch kanálech. Když objekt opustí instanci, tak už jej instance nevlastní. Vyřešeno dvacet.

Pokud se bavíme čistě jen o tom "kloudu" instancí, tak prostě klasický problém jako kdyby to byla databáze. Co se stane když někdo smaže prvek z kolekce v jiné instanci?:
Kód: [Vybrat]
trx = conn.startTransaction()
for x in range(trx.query(....)) { .... }
trx.commit()
A jsou na to už provařené odpovědi. Řekl bych.

17
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 01:46:21 »
Kód: [Vybrat]
let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
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?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?
Viděl bych to tak.

Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).

18
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 01:22:48 »
Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním? :)
Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.
No právě, když chci, aby se změnil, není úplně jednoduché to naimplementovat. Teoreticky to vypadá hezky, ale všichni víme, jak spolehlivé jsou sítě.

To je jistě problém. Ale nesouvisí s mou vizí. Má vize je: udělá to engine/jazyk. Aktuální situace: musím si to naprogramovat sám.

19
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 01:12:10 »
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

Jo, to se mi líbí. Tak ještě jak implementovat ten commit? Tím se ta Kitova špinavá cache přesune do ... transakčního manažera? A ten si udělá tu dočasnou kopii?
Jeho boj.
Atomický blok definuje, že dokavad ty změny nejsou provedeny všechny, tak žádné vlákno, a v našem případě ani žádná další instance aplikace sdílející stav, o tom nesmí vědět.
Stejně tak, když jsou transakce zanořené.

Jako je to úplná klasika, nic nového pod sluncem. Kdo dělá s DB, tak to určitě zná. Rozdíl je v tom, že tu máme transakčnost na úrovni jazyka, a nepracujeme (explicitně) s žádnou databází.

20
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 01:07:22 »
Tahle tvá úvaha o transparentní perzistenci mě vrací o 15 let zpátky, kdy jsem objektové databáze řešil v projektech. Těch problémů bylo víc, třeba existence více kopií stejného objektu v paměti (tehdy ještě nebyl Rust zajišťující unikátní měnitelné reference). Třeba ty typově bezpečné dotazy se běžně řešily přetěžováním operátorů.
Pojďme si o těch problémech pokecat. Zajímá mě to.

Celá ta má úvaha je postavená na tom, že data persisteuju implicitně. Jinak všechny techniky, které známe se budou používat podobně.

třeba existence více kopií stejného objektu v paměti
Úplně nevím, v čem by měl být problém...
Pět referencí na stejný objekt? (jsme v OOP), ok, bude pět referencí na stejný objekt i v jiné instanci. Změním hodnotu v první referenci, změní se i v těch devíti ostatních.
Čtyři kopie jednoho objektu? ok, bude pět separé objektů i v druhé instanci. Změním hodnotu jednoho objektu, změní se hodnota právě toho stejného objektu v druhé instanci.


Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním? :)
Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.

21
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 00:42:18 »
Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
transaction {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
fail (Error e) {
    console.log(e.message)
}
To jsou přejmenované výjimky ;)
Vypadá to podobně, že jo? :-)

22
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 00:34:01 »
Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
transaction {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
fail (Error e) {
    console.log(e.message)
}

23
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 00:24:33 »
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.)

A to takhle někde jde? A není to náhodou to stejné jako když se dva klienti připojují do SQL? Taky vidí stejné hodnoty... ...až na ty okolnosti při různém transaction isolation levels. Ale pokud uvažujeme úplně netransakčně -  kdo přijde, ten čte/mění - tam můžu sdílet paměť a při každé změně objektu tam zapsat novou hodnotu a při každém dotazu ji zase číst. A třeba může být ten zápis mezi klienty synchronizovaný (takže zapisovat budou vždy jeden po druhém, nikdy současně) Neuvažuju teď změny třídy jako takové, řekněme že se jejich definice za běhu nemění a mění se jen její fieldy (datové položky - třídní proměnné). Tak takový systém určitě bude fungovat. Ale zase k čemu vlastně bude? Typicky chci načíst objekt, nějak ho měnit, validovat a až nakonec naráz uložit. Pokud to bude dělat vše hned naživo, nechám ho v rozdrbaném stavu. Chtěl jsem takhle nějak použít ZooDB a došel jsem k tomu, že to asi nechci. Teda ještě si můžu objekt naklonovat, udělat změny, validovat a pak promítnout do původní instance. Ale to už jsme u toho attachování, které jsme vlastně nechtěli. Čili při běžném aplikačním programování se skrytě obvykle uvažují cca dvě verze instance - před změnou a po změně. Je to důsledek SQL/ORM architektury nebo obecný problém? Třeba active record pattern v ebean.io nemá attach/detach sémantiku (jede v jediné persistentní session, kterou asi ani neumí opustit), ale save() tam má. A ten si nedokážu představit bez řešení kolizí a bez transakčnosti, kterou naopak ebean.io má. Takže v praxi se podle mě naráží na stejné problémy, které mi přijdou jako obecné problémy při sdílení stavu mezi více procesy. Ale jeden benefit by tam u objektové databáze byt - absence mapování. Pokud by tam byly všechna ta synchronizační bižuterie okolo a pracovalo se přímo s object graphem bez ORM mappingu, bylo by to to co asi hledám.

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

24
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 25. 04. 2021, 00:12:50 »
Hlavně tam nesmí být takové to:
Kód: [Vybrat]
entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)
Jak bys řešil transakce?

Vycházíš z ne úplně odůvodněného předpokladu, že to mám promyšlené.

cca takhle, asi, možná:

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
try {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
catch (Exception e) {
    console.log(e.message)
}

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.


Shodou okolností reálný kód na neidealistické platformě (pseudokod):
Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
conn.transaction(conn => {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
    conn.flush(posts)
    conn.flush(users)
}, e => {
    console.log(e.message)
})

Výše uvedený kód by pak měl vypadat takto:
Kód: [Vybrat]
try {
    entity = users.find(anything)
    entity.name = "Jozef"
}
catch (Exception e) {
    console.log(e.message)
}


25
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 24. 04. 2021, 23:26:24 »
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.

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.)


PS: Jasně, SQL je taky způsob jak sdílet stav, ale otázka asi zněla zda to jde nějak víc napřímo.
Ani ne. Postgresql jako správce stavu může být klidně dobrý nápad. Ale je to implementační detail. Hlavně tam nesmí být takové to:
Kód: [Vybrat]
entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)

26
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 24. 04. 2021, 23:09:41 »
že se o to nemusel vývojář starat. Byla to vlastnost toho systému. Takže, čistě teoreticky, není problém aby si ten systém distribuovanost řešil sám, a všechno fungovalo naprosto transparentně.
Jako JavaSpaces?
Úplně dobře to neznám, ale přijde mi, že je to taky jen trochu vymazlenější Client/Server.

27
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 24. 04. 2021, 23:06:02 »
Distribuci změn dobře řešilo Lotus Notes/Domino nebo Groove.
Jak řešili konflikty?
U záznamů unifikací na úrovni polí. Domino má jako dokumentová databáze poddokumenty, tam končí konfliktní dokumenty, když se nedají data sloučit automaticky. Groove si už nepamatuju, ale navrhoval ho stejný člověk, takže asi podobně.
Díky.

28
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 24. 04. 2021, 23:05:24 »
Kromě Smalltalku ;)
Smalltalk 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í?
Ne, v praxi nesetkal.
Což je IMHO omezení toho konceptu. Sdílená paměť sice není problém, ale problém je asi distribuce změn.
Tohle vedlo ke konceptu distribuovaných objektů, což byl svého času rozšířený buzzword. Ale ty se taky neujaly.
IMHO distribuované objekty jsou trochu něco jiného. Nejsou to více provázaných instancí, ale klasicky klient server. Ve windows COM, na Linuxu CORBA, Java má RMI... Všechno se celkem používá. Nebo jsem tě nepochopil?

29
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 24. 04. 2021, 22:52:47 »
Distribuci změn dobře řešilo Lotus Notes/Domino nebo Groove.
Jak řešili konflikty?

30
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 24. 04. 2021, 22:51:00 »
Kromě Smalltalku ;)
Smalltalk 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í?
Ne, v praxi nesetkal.

Což je IMHO omezení toho konceptu. Sdílená paměť sice není problém, ale problém je asi distribuce změn. Protože dělat to celé synchronizované by byl výkonnostní nesmysl. A bez okamžité synchronizace se zas dojde k 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.
To bych neřekl. V čem se Smalltalkovské image liší od oddělené databáze jak to známe dnes je skutečnost, že se o to nemusel vývojář starat. Byla to vlastnost toho systému. Takže, čistě teoreticky, není problém aby si ten systém distribuovanost řešil sám, a všechno fungovalo naprosto transparentně.

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.

Stran: 1 [2] 3 4 ... 110