Příspěvky

991

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 00:51: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)
}

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?

992

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 00:41:03 »

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

993

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 00:33:42 »

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.

994

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 25. 04. 2021, 00:29:58 »

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?

995

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 23:49:07 »

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?

996

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 23:12:15 »

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

997

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 23:11:01 »

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?

Spíš DCOM než COM. Jeho použití moc nevidím, javovské RMI taky ne. Měl jsem na mysli spíš ty staré systémy DO od Sunu apod. integrované přímo do jazyků, které se neujaly. Standardy jako CORBA a SOAP se trochu chytly (i když dnes už o nich taky není moc slyšet).

998

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 23:00:12 »

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

999

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 22:58:42 »

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

1000

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 20:15:35 »

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.

Distribuci změn dobře řešilo Lotus Notes/Domino nebo Groove.

1001

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 18:36:58 »

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.

1002

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 15:13:04 »

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 + pravidla

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

No a jsme u toho. Pro spoustu malých projektů by stačil přístup Smalltalku.

To se taky moc nechytlo 

Hlavně se nechytla Gemstone database, což je škoda.

Což je ale IMHO dáno historickým kontextem.

Používal jste někdo Gemstone?

Kdysi dávno jsem používal její klon pro ObjC. Pracovalo se s tím velmi dobře.

1003

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 15:00:28 »

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 + pravidla

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

No a jsme u toho. Pro spoustu malých projektů by stačil přístup Smalltalku.

To se taky moc nechytlo 

1004

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 14:59:51 »

LINQtoSQL?

LINQ je náznak, jak by to zhruba mělo vypadat.

1005

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 10:54:58 »

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 + pravidla

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