MariaDB vs Postgres vs SQL Server

[BoneFlute]

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? :-)

[Reklama]

[Idris]

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? :-)

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

Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním?

[Ondrej Nemecek]

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?

[BoneFlute]

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.

[BoneFlute]

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

[Reklama]

[Idris]

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

[BoneFlute]

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.

[Idris]

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.

OK. Teď už jen brainstormuju, ale co když mám třeba:

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?

[Ondrej Nemecek]

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?

[BoneFlute]

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

[Idris]

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

To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.

[Ondrej Nemecek]

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

To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.

Ale v principu to jsou úplně stejné problémy konkurentního přístupu jako u jediné aplikace, ne? Které by šly řešit nějakou distribuovanou transakcí? Což tedy asi může vést k tomu že to jako celek bude hrozně pomalé a deadlockující...

[Idris]

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

To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.

Ale v principu to jsou úplně stejné problémy konkurentního přístupu jako u jediné aplikace, ne? Které by šly řešit nějakou distribuovanou transakcí?

Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.

[BoneFlute]

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.

[BoneFlute]

Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.

Mě se to nezdá. Na základě kanálů, které se začali používat v posledním roce dokazuješ, že se to proto neujalo?

IMHO se to neujalo proto, páč na začátku jsme u C byli rádi, když přišel GC. Pozdějc přišla móda dynamický jazyků se svým "hele jak hezky se to dá napsat". A pak už se usadil ten mindset, že data se vytahují a vrací z/do persistence. Technické obtíže bych v tom nehledal.