Potrzebuję trzymać globalne konfiguracyjne ustawienia w bazie danych. Rzeczy typu adres mailowy do wysyłania błędów aplikacji, stan którejś opcji typu włącz/wyłącz itp. Ustawienia mogą być 4 typów: integer, string, float, boolean.
Jeślibym z góry wiedział ile to ma być zmiennych, to nie ma problemu: tabela Settings i poszczególne pola. Nic prostszego.
Co jeśli jednak chcę mieć możliwość lotnego dodawania zmiennych bez potrzeby pisania kolejnej migracji za każdym razem? Jak byście to rozwiązali?
Dla szybszego działania bym jeszcze wszystko dał do cache’a, ale to już pewnie coś w stylu
*find(:all).map { |pair| [pair.key, pair.value] }.flatten
i dałbym to do hasha, którego bym trzymał w memcache’u.
W wielojęzykowości: YAML jest prawie równie uniwersalnym formatem jak JSON, tzn. biblioteki do jego łykania posiadają wszystkie co-popularniejsze języki programowania.
No i jest czytelniejszy (human-readable) niż Marshal
[quote=Tomash]W wielojęzykowości: YAML jest prawie równie uniwersalnym formatem jak JSON, tzn. biblioteki do jego łykania posiadają wszystkie co-popularniejsze języki programowania.
No i jest czytelniejszy (human-readable) niż Marshal :)[/quote]
Nie zapominajmy że w programowaniu nie ma absolutnych odpowiedzi i rozwiązań. YAML może jest czytelniejszy i lepiej nadaje się do plików konfiguracyjnych czy serializowania ustawień ale obecna jego implementacja potrafi być 20x wolniejsza niż Marshal. Wszystko zależy od zastosowań - do serializacji milionów obiektów lepiej wybrać jednak Marshal’a
[quote=hosiawak][quote=Tomash]W wielojęzykowości: YAML jest prawie równie uniwersalnym formatem jak JSON, tzn. biblioteki do jego łykania posiadają wszystkie co-popularniejsze języki programowania.
No i jest czytelniejszy (human-readable) niż Marshal :)[/quote]
Nie zapominajmy że w programowaniu nie ma absolutnych odpowiedzi i rozwiązań. YAML może jest czytelniejszy i lepiej nadaje się do plików konfiguracyjnych czy serializowania ustawień ale obecna jego implementacja potrafi być 20x wolniejsza niż Marshal. Wszystko zależy od zastosowań - do serializacji milionów obiektów lepiej wybrać jednak Marshal’a[/quote]
Tak samo jak do zapisywania pojedynczego ustawienia które będzie odczytane przy każdym requescie…
Czyli
a) nie przeczytałeś posta otwierającego wątek (ile razy w trakcie cyklu życia aplikacji zmienia się adres mailowy do exception_notifiera?)
b) railsowe i18n według Ciebie się do niczego nie nadaje
Dobrze zrozumiałem?
A tak poważnie, to bądźmy poważni. Faktor “20x” brzmi oczywiście efektownie, póki nie okaże się że jest to (w danym przypadku dla danych potrzeb) różnica pomiędzy 0.1ms a 2ms. Jeśli ktoś z tego tylko powodu wybierze Marshala zamiast YAMLa, ignorując wszystkie pozostałe przewagi tego drugiego nad tym pierwszym (uniwersalność, wielojęzykowość, human-readability itd.), to ja wysiadam.
Jako eksperyment myślowy proponuję zbenchmarkować jeszcze JSONa wraz z tą dwójką. A potem się zastanowić czemu pomimo tego [wolnych bibliotek do (de)serializacji dla Ruby] jest on “industry standard” w wymianie danych.
Koleś się podnieca w README, że dla 10k wykonań (nie wiem do końca czego) Riot jest szybszy aż 2 razy! Przy niewyobrażalnie długim czasie dla Test::Unit 1.5 sekundy, Riot wykonał się miażdżąco szybko, 0.6 sekundy! Podejrzewam, że przy realnych restach różnice będą w granicach błędu statystycznego… Ale tak… Riot jest szybszy.
(ile razy w trakcie cyklu życia aplikacji zmienia się adres mailowy do exception_notifiera?)