Když je zničená, tak negeneruje eventy. 

Řešení zůstává jak bylo, jenom je optimalizace, že se zpátky do DB ukládají jen objekty, které byly čtené.

Je jedno, kdy to zapíšu do DB. Není, co když spadne server? No tak se obnoví poslední konzistentní stav. No neobnoví, to se smazalo v DB. Ale to se vrátí všechna uloží. Mluvíme o transakci DB. Ukládáme jednou za čas. Řekněme akždou hodinu to, co se změnilo. Je třeba 12 h, uloženo. Je 12:30. Když spadne server, vracíme se na 12:00. Když ve 12:15 smažu objekt v DB, už se nemůžu vrátit k 12:00. Problém. No není, jsme přece v transakci. Není dobré ukládat po minutě, to se přeplníme. Nevíme to jistě, ale asi se to přehltí. O možná ne, to by byl problém pro 20 klientů. Když máme jednoho, tak je to ok. U Nepřehltí se DB, ale server. Protože musíme každou chvíli ukládat moc dat. O Diskutabilní. U Ne, už jen protože fungujou senzory, tak musíme určitě každou chvíli ukládat hodně dat do DB. Pokud tohle bude každou minutu, tak pokud to stojí každou minutu 5 s, je to dost problém. A to určitě bude trvat vteřiny. O Je otázka, jak to řeší firebird. Možná řeší v jiném vlákně. U Mluvíme ale o našem serveru. Musí ve forcyklu projít všechny předměty, to trvá několik vteřin. O Jen ty, co se načetly. U Všechny načtené předměty musíme každou minutu procházet v cyklu, což je smrtelný. Takže to dělat třeba jednou za hodinu. Nemůžeme to ale dělat každou minutu. Už jen proto jak fungují senzory je v listech děsně moc dat. Kopírování třeba 1000 objektů zabere vteřiny, jednu dvě, to by vypadnul během toho server, to je blbý. Takže to nemůžeme dělat tak, že máme celou dobu otevřenou transakci. Akorát si poznamenám u předmětu, že byly smazané. Takže si poznačím, že je předmět smazaný, zavolám destruktor na něj a do cashlistu si poznačím, že je smazanej. Když to pak ukládám do DB, tak místo save ho smažu. Kdykoliv si do listu přiřadím předmět, který musím updatnout, tzv. updatelist, tak kdykoliv tam najdu předmět co není v cashlistu, tak je jasné, že se smazal, jinak by se tam nemohl objevit. Když z cashlistu vracím tedy null, tak si to neuložím. Když potřebuju updatnout předmět, co neexistuje, tak ho prostě smažu. Můžu si udělat updatelist, insertlist, deletelist. O Co když se pak smaže insertovanej list? U tak nejprve projdu insert. Projedu je insert, update, delete. Tím řeším tenhle problém. Když mám v insert listu předmět, co neexistuje, tak ho přeskočím. 

Pokud chci smazat předmět, tak jen do listu napíšu, že ho chci smazat. Zavolám funkci listu, aby ho smazal, o desktrukci už se postará list. Tímhle řešíme i to, že můžeme znovu používat staré ID. O Ale nemusíme. U Ale měli bychom. Minimálně u například předmětů, protože můžou snadno překročit limit. Teoreticky. Není to určitě nedosažitelné množství. 10 000 hráčů, každý vytvoří 100 předmětů denně a za pár let mám 4 miliardy. A to předpokládáme, že to bude na dlouho, třeba pár let.Takže znovu používat ID můžeme. O Není jisté, že to jde u všeho. U Každý list at je nastavitelný, jestli chceme znovu používat ID nebo ne. 

Jakub první dva dny bude dělat listy a DB a ukládání. Teď funguje ukládání do DB pro každý předmět, že mají funkci pro uložení, ale nikdo to nevolá. 

Jednou za hodinu ukládám do DB. Je potřeba k tomu ukládat datetime, herní čas. 

Nebudeme dělat:
Transportní paprsek. Průzkumné zařízení. 

Budeme dělat, ale časem:
Maskování bude snadný udělat, ale teď to není priorita, v podstatě to patří k senzorům. 
Senzory, k tomu musí udělat Urza na serveru podporu, takže to určitě budu dělat, ale až to Urza dopíše. 
Androidi. Musím udělat, zatím se odkládá. Tam bude hodně práce.

Mám udělat:
Ubikace můžu udělat, komplet.
Vybavení. 
Továrny můžu udělat, jsou komplet funkční. 
Sklady udělat. 

Hangáry jsou do jisté míry, můžou se propojit. To je to, co dělal Martin, nejsou to sklady. 

Kus pátku, celou sobotu a kus neděle tu Urza nebude.