Na koniec pokazujemy słynny scentralizowany plik ustawień, o którym wspominaliśmy w całym przykładzie. Jak widać, jest to po prostu lista list zawierająca parametry określające, jak powinien zachowywać się nasz system. Scentralizowanie tych opcji w jednym pliku, tak jak tutaj robimy, może być często bardzo wygodne. Zamiast zmieniać kod, gdy chcemy innych zachowań z naszego systemu, możemy po prostu zmienić ten plik, a wszystko zostanie za nas załatwione:
SETTING <- list (
„debug” = TRUE,
„storage” = list (
„read” = list (
„name” = „CSVFiles”,
„envronment” = „production”
),
„write” = list (
list (
„name” = „CSVFiles”,
„environment” = „production”
)
),
„table_names” = list (
„production” = list (
„assets” = „production_assets”,
„markets” = „production_markets”,
„users” = „production_users”,
„wallets” = „production_wallets”,
),
„development” = list (
„assets” = „development_assets”,
„markets” = „development_markets”,
„users” = „development_users”,
„wallets” = „development_wallets”,
)
)
),
„batch_data_colletion” = list (
„assets” = list (
„minutes” = 60
),
„markets” = list (
„minutes” = 60
)
)
)
W szczególności zwróć uwagę, że istnieje wartość logiczna debug, której ostatecznie nie używaliśmy, ale która może być przydatna podczas debugowania naszego systemu w pewnym momencie. Zwróć również uwagę, że istnieją dwie główne części naszego pliku ustawień, część storage i część batch_data_ollection. Część storage jest tą, z której korzystaliśmy do tej pory i zawiera specyfikację dla jakich baz danych powinny być używane do odczytu i zapisu danych poprzez podanie nazwy implementacji, która ma być zastosowana w elementach names , a environment na której aktualnie pracujemy , którym może być albo product lub development. Oba te elementy są wykorzystywane przez czynniki do odpowiedniego skonfigurowania systemu, zanim zacznie on działać. Zwróć również uwagę, że pliki CSV, które zostaną utworzone, odpowiadają ciągom znaków znalezionych w elemencie i będą się różnić w zależności od enviromnment bazy danych, w której ma działać.