Temat dla mnie zupełnie nowy - wczoraj dopiero zacząłem poważniej szperać w sieci szukając tego zagadnienia.

Problem jest następujący : Konnekt przechowuje masę ustawień własnych, do tego jeszcze dochodzi archiwum wiadomości, wtyczki... Aktualnie wszystko to jest przechowywane w plikach *.dtb, obsługiwanych przez bibliotekę autorstwa hao. Niestety, czasem się sypie [np. przy padzie programu zdarza się, że ustawienia diabli biorą, albo z archiwum zniknie jakiś rozmówca].

Owszem, można robić backup profilu codziennie... Ale to jest obejście, nie rozwiązanie.

Może ktoś zna / znajdzie alternatywną bibliotekę działającą skuteczniej?

Jak powinna działać?
Konnekt zapisuje dane jako pary (klucz, dana), gdzie klucz jest unikalnym int'em. Dane są typu char* (niedługo możliwe, że zostaną zastąpione przez std::string), int lub __int64 . Nie istnieją relacje między danymi. Dostęp do konfiguracji chroniony jest hasłem. Konfiguracja może być używana przez wiele wątków na raz, dane zapisane nie mogą być utracone (tutaj właśnie *.dtb potrafi nawalić). Kluczowe są niska złożoność pamięciowa i duża szybkość operacji. Licencja - koniecznie darmowa, może być OpenSource ale nie może narzucać takiej licencji wykorzystującemu ją programowi (czyli LGPL tak, GPL nie).

Bonusem byłby mechanizm obecny np. w DB Oracla - możliwość zaglądania w historię i cofania zmian... dobra, nie przesadzajmy :P .

Gdzie mogłem się pomylić : nie wiem, czym rózni się archium od reszty konfiguracji; nie wiem, czy potrzebna jest możliwość uzyskania atomowości transakcji.

W mirandzie wprowadzają SQLite do bazy danych programu, tak gdzieś słyszałem. To chyba przesada ;-)

SQLite to imho zdecydowana przesada... Chociaż przydałoby się kilka dodatkowych bajerów wspomagających _proste_ relacje.

Pady DTB zdarzają się w większości przypadków gdy crossują się pliki na dysku, tutaj wiele nie pomożemy, można co najwyżej rzadziej zrzucać do pliku. Myślałem żeby dodać automatyczny krótki backup plików, tak żeby w razie czego "przeźroczyście" cofnął do poprzedniej kopii.

Sama baza danych musi dodatkowo do tego co wymienił skolima:
- obsługiwać szybkie dopisywanie (historia rozmów to doklejane pojedyńcze wiersze na końcu i zwiększany counter) bez potrzeby przebudowywania w _żadnej_ sytuacji
- obsługiwać szybkie usuwanie (w tej chwili cały wiersz jest po prostu zerowany)
- obsługiwać "przeglądanie" (możliwość szybkiego przejrzenia bazy bez konieczności wczytywania jakichkolwiek danych)
- być kompatybilna w dół
- działać niezależnie od definicji danych dostarczonych przez program (dtb wczytuje deskryptor kolumn z pliku i dostaje podobny od aplikacji, podczas wczytywania i zapisywania danych odbywa się konwersja typów, brakujące pola uzupełniane są wartościami domyślnymi... W ten piękny sposób struktura plików dtb zmieniła się na przestrzeni dwóch lat bardzo, a jeszcze nie było problemów z kompatybilnością)

Kod do DTB będzie najprawdopodobniej udostępniony razem ze Stamina.lib... Piszę najprawdopodobniej, bo najpierw trzeba w niej zmodyfikować kilka rzeczy...

Backup danych przy zapisie jest chyba tutaj kluczem. Zastosowano go chociażby w eMule dla indeksów plików (choć jak praktyka pokazuje - pojedynczy backup czasem nie wystarcza i niektóre mody mają zapas podwójny). Do wymienionych rzeczy, HAO, powinno dojść jeszcze kompaktowanie (czy też defragmentowanie) danych. Nie bardzo rozumiem co masz na myśli pisząc 'kompatybilna w dół' - kompatybilna z DTB?

Chodzi o to żeby w nowej wersji bez problemu odczytywalne były stare pliki i na odwrót...

Na odwrót to kompatybilność w górę... a to chyba nie jest sensowne wymaganie. Owszem, fajnie by było, ale wymagając tego przesiadki raczej nie da rady zrobić, ani poważniejszych zmian.

Olórin: ja doskonale wiem co to kompatybilność w dół - pytałem wyłącznie z powodu podobnego do skolimy podejścia - zachowanie komatybilności w dół w ogólnym rozumieniu tego zwrotu odbije się czkawką na jakichkolwiek zmianach (nie mówię, że kompatybilność jest be, ale czasem nie jest wskazana). Miałem nadzieję, że jednak hao chodziło o coś innego.

Chodzi mi o kompatybilność samej implementacji... Oczywiście moment zmiany samego systemu nie musi być już aż taki kompatybilny...

Z drugiej strony, DTB przepoczwarzyło się znacznie od pierwszej wersji i nigdy kompatybilność w dół nie została utracona... Od kilku wersji istnieje nawet częściowa komaptybilność w górę

Myślę że dtb z odpowiednim wsparciem backupów pociągnie jeszcze długo... Zauważcie na przykład, że niewiele jest zgłoszeń o psujących się plikach historii, padają zazwyczaj tylko te które są często zapisywane od podstaw...

Hao? Czy K w ramach zbierania statystyk wysyła informacje o walniętych plikach konfiguracyjnych? Tak jak zgłasza błędy? Bo jeśli opieramy się tylko na forum... większość ludzi nie będzie o takim problemie pisać.

Forum przedstawia statystyczną reprezentację użytkowników Mi na przykład, mimo (zrozumiałego chyba ) bardzo intensywnego użytkowania pliki konfiguracyjne nie padły ani razu

a gdyby lock'owac pliki dtb przez jakis inny watek / proces ??? tak by konnekt odpalal inny watek i blokowal pliki dtb a w chwili potrzeby dostania sie do danego dtb watek bylby zwalniany, dtb odblokowany ?

A co by to dało ? Generalnie większość błędów w dtb spowodowana jest uszkodzeniem systmu plików.

a program nei mógł by robic 2 tych plików i gdy jeden by sie nei załądował to drugi by się ładował ..?

Półśrodek...

W tej chwili już jest tak że zapisuje do pliku tymczasowego, _sprawdza_ czy zapisało się poprawnie i podmienia na stary (bez użycia kopiowania, usuwa stary, zmienia nazwę nowemu)... W praktyce niestety szyki miesza crossowanie plikow na dysku... A to akurat problem aktualny przy dowolnym formacie plików :|

Pomysł na rozwiązanie problemów jest taki:

1 zapisujemy do pliku tymczasowego - jak dotychczas
2 jeżeli zapis się nie uda przerywamy (ew. pokazując okienko z informacją)
3 zmieniamy nazwę aktualnego pliku na nazwę backupową (np. cfg-data.bak)
4 zmieniamy nazwę tymczasowego na docelowy
5 co któryś zapis (sprawdzamy po prostu losując) uruchamiana jest funkcja kasująca stare pliki... Pozostawia po sobie najnowsze kopie z kilku "kategorii" : z przed miesiąca, z przed tygodnia, z wczoraj, z przed 6 godzin i oczywiście najnowszą kopię...

Punkt 3 też może być losowany, żeby zbyt częste zapisywanie nie robiło zbyt dużo zbędnego ruchu na dysku (psując fragmentację na przykład).

Podczas wczytywania, gdy plik okaże się uszkodzony pojawia się stosowna informacja i po zatwierdzeniu ładowany jest plik poprzedni... Operacja powtarzana cyklicznie aż do wyczerpania zapasów... (użyty backup może być kasowany, lub może zmienić nazwę, na wszelki wypadek na później)...