MariaDB vs Postgres vs SQL Server

[Idris]

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

Javovskou verzi taky neznám do hloubky, ale původní koncept “tuple spaces” byl spíš P2P.

[Reklama]

[Ondrej Nemecek]

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

[BoneFlute]

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)

[Idris]

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?

[Kit]

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?

Tohle právě nemá s transakcemi nic společného. Když místo toho použije UPDATE, tak je to transakce by design.

[Reklama]

[BoneFlute]

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

[Ondrej Nemecek]

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.

[Kit]

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

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.

[Ondrej Nemecek]

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.

Dobře, tak ho už mám, změní se v uvažování něco? V podstatě můžu spouštět vlákna ve stejném procesu, pracovat nad stejnou pamětí, ale lze to nazvat databází? Ale bude to asi nejpodobnější tomu Smalltalku.

[BoneFlute]

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

[Kit]

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.

Dobře, tak ho už mám, změní se v uvažování něco? V podstatě můžu spouštět vlákna ve stejném procesu, pracovat nad stejnou pamětí, ale lze to nazvat databází? Ale bude to asi nejpodobnější tomu Smalltalku.

Ano, změní: Základním pravidlem je: Tell, don't ask. Když to neuděláš, děláš ze svého objektu v paměti cache. A špinavé cache jsou jedním ze dvou zel v programování právě proto, že demolují transakce.

[Idris]

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

Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

[Idris]

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

Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.

[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)
}

[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