Konwersja daty

Zielona szkoła
1

Cześć,
importuję bazę danych ze starego portalu mam w nim format daty => 1224441955 i chcę go przekonwertować na format obsługiwany przez devise => 2011-04-14 00:11:45.356875
jak to zrobić?

2

t= Time.at(1224441955) => 2008-10-19 20:45:55 +0200

3

okej, a jak to rozwiązać najlepiej, jeżeli będę dodawał nowych użytkowników poprzez devise i będą mieli oni inny format. Zmienić domyślny format gdzieś w configu devise?

Chyba, że da sie w excelu jakoś szybko konwersję zrobić.

Narazie mój pomysł to użycie tej funkcji t= Time.at dla użytkowników do id=250 bo tylu zaimportuje.

4

Nie do końca kumam o co Tobie chodzi. Po co chcesz zmieniać format daty devise? Przekonwertuj format starych użytkowników i święto lasu, jeśli o to chodzi.

No prośba… :stuck_out_tongue:

A co jak Ci się poprzestawiają indeksy w bazie? Nie jesteś w stanie scharakteryzować ich w żaden inny sposób? Jako jednorazowa akcja może Twoja koncepcja jest słuszna, ale raczej się powinno unikać takich rzeczy.

5
  • Datę ze starej bazy wstaw do kolumny created_at_old.
  • Dodaj standardową kolumnę created_at
  • Napisz migrację, która wstawia created_at na podstawie created_at_old.
  • Napisz migrację, która usuwa created_at_old.
  • Odpal całość na produkcji
  • Usuń zbędne migracje z kodu
6

Jak to będzie wyglądać?
t.Time.at(created_at_old)

7

Nie sądzę, aby udało się Tobie wywołać klasę na jakimś enumeratorze (t.Time)

przykład, najbardziej prostacki z możliwych:

class JakasMigracja < ActiveRecord::Migration
  def self.up
    Object.where("id <= 250").each do |o|
      o.created_at = Time.at(o.created_at_old)
      o.save!
    end

    remove_column :objects, :created_at_old
  end
end

Wyprzedzając Twoje pytanie, zamiast Object podstaw Twoją nazwę klasy.

8

Jak to będzie wyglądać?
t.Time.at(created_at_old)[/quote]
Nie, w tej migracji musisz po prostu odszukać wszystkie rekordy, przelecieć po każdym z nich i ustawić pola jak trzeba. Bragi na pewno zapomniał napisać że to antywzorzec i ogólnie bardzo zła rzecz, ale w tym wypadku zgodzę się że chyba najłatwiejsza do zrobienia.

9

Zrobiłem screenshota tego wątku, tylko spróbuj teraz kogoś ochrzanić za złe praktyki i antywzorce :stuck_out_tongue:

10

Migracje to taki sam kod jak każdy inny. Przy dużym projekcie wymaga refactoringu, bo zmieniają się wymagania, modele komplikują (znikają, pojawiają się).

Migracje również trzeba porządkować. Nikt nie twierdzi, że masz mieć do dyspozycji całą historię zmiany bazy w działającej aplikacji. Po to jest Git, prawda?

11

Usuwanie migracji jest antywzorcem. Jeśli tego nie rozumiesz, to spróbuj wymyślić kilka scenariuszy pt. “programista stwierdza że dana migracja już nie jest potrzebna i postanawia ją usunąć”. Może nie będę musiał przywoływać horrorów z życia wziętych.

12

Jak się mają zmiany w modelu do migracji ? Przecież migracje z założenia nie powinny używać modelu.

Swoją droga ja wychodzę z założenia, że migracje tylko powinny zmieniać scheme / korzystać z sql by wykonać operacje na istniejących już danych. Jakieś rzeczy typu przenieś innych userów z bazy danych z poprzedniego projektu albo inne tym podobne dziwa to z ręki powinno się robić.

13

I odradzam używanie modelu w migracjach o ile nie jest mega prosty i zdefiniowany w tej migracji.

Takie rzeczy jeszcze przejdą moim zdaniem:

[code]class JakasMigracja < ActiveRecord::Migration
class User < ActiveRecord::Base

end

def self.up
User.update_all(“forum_login = login”) # User cannot have different login for forum since now.
end

end[/code]
Ale nigdy nie używaj User z app/models/user.rb . To tylko głupi przykład który daje to, że nie trzeba sql z ręki pisać tylko można sobie nieco pomóc używając AR ale daje pojęcie jak można stosować modele w migracji.