Tag: RoR

Rails3 + link_to + update z pominięciem edit

Ostatnio przeglądając kod Redmine'a natknąłem się na fajny kawałek kodu. Nigdy się nad tym nie zastanawiałem i w zasadzie, nigdy zbytnio nie potrzebowałem.

Jak za pomocą linka, zaktualizować wybrany atrybut instancji modelu?

Zazwyczaj do aktualizacji danej instancji korzystam z edit'a oraz forma odpowiedniego do tego. Dzisiaj jednak nadarzyła się  ku temu okazja.

Mam w systemie model o nazwie Cron który odpowiada za cykliczne odpalanie komend/metod które są w nim yieldowane. Np:

    Cron.backup{
      # Wykonaj nową kopię zapasową
      Backup.create
      # Usuń stare kopie zapasowe
      Backup.sweep(Setting::Cron.backup_lifetime)
    }

Powyższy "cron" o nazwie backup odpala się co 7 dni wykonując kopię zapasową systemu. Usuwa przy okazji kopie starsze niż backup_lifetime. Z ciekawostek warto wspomnieć, że dzięki "fajności" Rubiego, mogłem napisać sobie w bardzo prosty sposób własne mapowanie, nie po kolumnach a po wierszach. Właśnie dzięki temu metody modelu Cron są generowane dynamicznie. Ale to jest temat na oddzielną notkę.

Wracając do sedna sprawy. Model Cron korzysta z pola updated_at aby określić kiedy Cron był ostatnio odpalany. Jeśli było to dawniej niż zadana w instancji częstotliwość - uruchamia kod yieldowany.

Problem pojawił się kiedy chciałem dorobić "wymuszone" odpalenie instancji Crona. Najprostszą metodą do zrobienia tego, było wyedytowanie updated_at i nadanie mu wartości np. 1.year.ago. Rozwiązać można to było tworząc metodę w stylu force. Nie byłoby to jednak zgodne z RESTem. Bardzo fajnie rozwiązano to w Redminie. Mianowicie tworzony jest link_to który zawiera wszelkie potrzebne informacje. Jak taki link wygenerować? Bardzo prosto:

link_to "Wymuś", cron_path(task, 'cron[updated_at]' => 1.year.ago), :method => :put

Metoda link_to stworzy nam link który zostanie zrealizowany przez metodę update na instancji modelu Cron. Dzięki dodaniu parametru:

'cron[updated_at]' => 1.year.ago

informujemy Railsy, że ma naszemu cronowi przypisać datę ostatniego wykonania na rok wstecz. Dzięki temu, przy najbliższej możliwej okazji, kod z Crona zostanie zrealizowany.

Rails + MySQLDump czyli robienie kopii zapasowej bazy danych z poziomu Railsów

Zabezpieczenie systemu jest (jak nie muszę przekonywać) bardzo ważną sprawą. Jedną z podstawowych metod zapewnienia bezpieczeństwa systemu jest regularne wykonywanie kopii zapasowych bazy danych. Wprawdzie w Ruby on Rails nie istnieje ujednolicony interfejs do wykonywania tej czynności, jednak bardzo prosto można napisać własny model wykonujący dumpa.

Model jest bardzo prosty. Jeśli chodzi o migrację to zawiera ona tylko timestampy (created_at, updated_at). Jeśli chodzi o klasę, to jej szkielet wygląda tak:

# coding: utf-8

require 'fileutils'

# Służy do wykonywania kopii zapasowych plików oraz bazy danych
# Działa dla MySQLa - robi dumpa bazy
class Backup < ActiveRecord::Base
  # Zawartość
end

Dalej nie jest trudniej :) Musimy ustalić prefiks dla nazwy pliku, który będzie przechowywał nasz zrzut:

  # Prefix do nazwy backupu bazy danych
  DB_NAME_PREFIX = 'db_'

Oraz nadpisać metodę create, która oprócz utworzenia wpisu w bazie danych, utworzy nam także nasz zrzut.

Aby wykonać zrzut, musimy mieć dostęp do kilku informacji:

  • Nazwa bazy
  • Login
  • Hasło
  • Host
  • Możliwość wykonywania poleceń zewnętrznych
  • Ścieżka do backupu

Tak naprawdę, nie potrzebujemy niczego szczególnego. Zanim jednak przystąpimy do tworzenia naszej metody create, omówmy sobie jeszcze jak ma wyglądać przechowywanie kopii zapasowych.

Proponowałbym utworzyć logiczną hierarchię dla plików i katalogów. W głównym katalogu aplikacji, tworzony będzie katalog backup/. W nim będą subkatalogi, których nazwy składać się będą z daty oraz czasu wykonania kopii. W środku takiego subkatalogu będzie spakowany zrzut bazy.

Idąc za ciosem, zdefiniujmy sobie metodę prywatną, która sprawdzi nam czy katalog backup/ oraz jego subkatalog istnieją. Metoda ta jest na tyle prosta, że nie ma co jej opisywać. Komentarze powinny wystarczyć:

  # Sprawdzamy czy ścieżka gdzie ma być backup istnieje i jeśli nie to ją
  # utworzymy
  # Jako parametr podajemy czas - to jest nazwa folderu jako sygnatura czasowa
  # momentu rozpoczecia backupowania, czas w formacie Time.now.strftime("%Y\-%m\-%d_%H\-%M\-%S")
  def check_path(time)
    # Sprawdzajmy czy struktura katalogow jest cala - od poczatku (wiem że to
    # narzut tych kilku sprawdzen, ale tak jest prościej)
    full_backup_path = "#{Rails.root}/backup/#{time}/"
    check_path = ''
    full_backup_path.split('/').each { |el|
      check_path += "#{el}/"
      Dir.mkdir(check_path) unless File.directory?(check_path)
    }
  end

Mając już metodę, która zapewni nam, że będzie gdzie przechowywać plik ze zrzutem, możemy przystąpić do pisania metody create.

Pierwszą rzeczą jaką musimy zrobić, jest zapamiętanie czasu w którym przystąpiliśmy do tworzenia backupu. Jest to bardzo istotne, ponieważ jeśli operowalibyśmy na Time.now mógłby on różnić się dla subkatalogu oraz nazwy pliku (i ew. wpisu w bazie), co prowadziłoby do wielu problemów. Ominiemy je jednak wykonując na początku metody taki fragment kodu:

  # Nadpisujemy domyślne create żeby wykonywało kopię
  def create
    # Potrzebujemy jeden czas dla plików i dla utworzenia obiektu modelu Backup
    time = Time.now
    super
    self.created_at = time
    self.save
    # Musimy mieć czas w takim formacie aby dało się tym nazwać pliki
    file_time = time.strftime("%Y\-%m\-%d_%H\-%M\-%S")

Zapamiętaliśmy w zmiennej time aktualny czas, zapisaliśmy go także jako wartość created_at dla backupu. Na końcu konwertujemy czas do formatu który będzie stanowił nazwę dla naszego subkatalogu (np 2010-09-20_19-12-56).

Mając już "globalny" czas, możemy sprawdzić (i jeśli trzeba - a trzeba na pewno ;)) i utworzyć strukturę katalogów dla kopii zapasowej. W tym celu wywołamy następujący kod (który napisaliśmy wcześniej):

     # Jeśli nie ma katalogu na backupy to go utwórz
    check_path file_time

Ustalmy teraz jak ma nazywać się plik z kopią zapasową bazy i gdzie ma się znajdować:

    # Ścieżka gdzie ma zapisać plik bazy danych
    backup_db = "#{Rails.root}/backup/#{file_time}/#{DB_NAME_PREFIX}#{file_time}.sql.bz2"

Teraz pozostało nam tylko wyciągnąć parametry dostępowe do bazy oraz wykonać dump:

    db = self.configurations[Rails.env]['database']
    db_user = self.configurations[Rails.env]['username']
    db_pass = self.configurations[Rails.env]['password']
    db_host = self.configurations[Rails.env]['host']

    # Zrzut bazy danych
    exec "mysqldump --add-drop-table -u #{db_user} -p#{db_pass} -h #{db_host} #{db} | bzip2 -c > #{backup_db}" if fork.nil?

Baza po zrzucie zostanie spakowana.

Mamy już kopię zapasową oraz odpowiadający jej model. Musimy jednak zapewnić sobie możliwość usuwania powstałych kopii. Aby tego dokonać nadpiszemy metodę destroy w taki sposób aby usuwając instancję modelu, usuwała także korespondujący katalog z kopią zapasową:

  # Usuwa stary backup oraz zadane pliki do niego
  def destroy
    return if self.new_record?
    dir = "#{Rails.root}/backup/#{self.created_at.strftime("%Y\-%m\-%d_%H\-%M\-%S")}"
    # Usuwamy katalog z backupem
    FileUtils.rm_rf(dir) if File.directory?(dir)
    super
  end

To by było na tyle. Zachęcam Was do utworzenia w analogiczny sposób, kodu odpowiedzialnego za backupowanie plików userów - np katalogu /public/uploads/.

Copyright © 2025 Closer to Code

Theme by Anders NorenUp ↑