Hej Próbuję zrobić update bazy ale niestety coś nie idzie. Ciągle mi wywala coś w stylu: Called from /home/.rbenv/ versions/2.2.2/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/activerecord/connection_adapters/postgresql_adapter.rb:44:in ‘new’
tutaj niby leci execute
updateKolumnaTabela: migrating
updateKolumnaTabela: migrated (0.0000s)
Nie mam pojęcia dlaczego tak się dzieje i zupełnie nic się nie zmienia w bazie. To poszło? Nie poszło?
Ogólnie słabo to widzę. Zero jakiegoś sensownego feedbacku.
Mój kod
class UpdateKolumaTabela < ActiveRecord::Migration
revert do
reversible do |dir|
dir.up do
execute %Q(
UPDATE tabela
SET kolumna1 = 'foo'
WHERE kolumna2 = 'FO'
)
end
dir.down do
execute %Q(
UPDATE tabela
SET kolumna1 = 'Foo'
WHERE kolumna2 = 'FO'
)
end
end
end
end
Nikt Ci nie pomaga, spróbuję zgadnąć dlaczego. Syntax którego użyłeś do migracji jest skomplikowany motzno, musiałem odpalić dokumentację żeby w ogóle się dowiedzieć co robią te bloki. Z doświadczenia powiem Ci, że nie widziałem żeby ktoś ich używał. Tak, imo, powinna wyglądać Twoja migracja (pomijam kwestię nazewnictwa, zakładam że tylko się bawisz):
class UpdateKolumnaTabela < ActiveRecord::Migration
def up
execute "UPDATE tabela SET kolumna1 = 'foo' WHERE kolumna2 = 'FO'"
end
def down
execute "UPDATE tabela SET kolumna1 = 'FO' WHERE kolumna2 = 'foo'"
end
end
(zmieniłem warunki, migracja do góry i w dół nie powinna zmienić stanu, o ile się da)
Teraz tak, możesz się oczywiście bawić z blokami revert i reversible, ale serio, nie umiem wtedy pomóc i wygląda to mega nieprzejrzyście.
/home/.rbenv/ versions/2.2.2/lib/ruby/gems/2.2.0/gems/activerecord-4.2.0/lib/activerecord/connection_adapters/postgresql_adapter.rb:44:in 'new' – to jest tylko część stacktrace’a, jeśli faktycznie masz tam błąd, musisz wkleić więcej.
Co do tego co widzisz w migrating … migrated, ActiveRecord ma to do siebie, że (mam nadzieję, że nie kłamię) wypisze Ci co się stało w migracji o ile użyjesz jego syntaxu (update_column/create_table/add_index, blablal). Jeśli wywołujesz czysty SQL executem, czy updatujesz rekordy, to raczej nic tam nie zobaczysz. Możesz sobie dodać putsy jeśli chcesz widzieć, że coś tam się odpaliło.
Hej,
dziękuję za odpowiedź, ogólnie jestem bazodanowcem i jak widzę tego typu kombinacje to się zastanawiam czemu to ma służyć i jakoś nie znajduję odpowiedzi, da się to zrobić jedną zgrabną funkcją w bazie bez całego tego kombinowania za to z kompletnym zabezpieczeniem bazy i bez dodatkowych narzutów czasowych i pamięciowych ze strony orma.
Ale wracając w tym pomógł mi kolega, okazało się że faktycznie ta składnia jest mocno skomplikowana, aczkolwiek sam update przechodził bo po sprawdzeniu statusu okazało się że zadziałało. Faktycznie przepisaliśmy go na coś podobnego i wtedy poszło.
W przypadku odpalania czystych SQL przy pomocy execute, nie powiedziałbym, że ORM Ci bardzo przeszkadza, a dostajesz za darmo połączenie do bazy danych (nie musisz nigdzie osobno podawać credentiali).
A migracje są, imo, bardzo przydatne jeśli utrzymujesz kilka środowisk i musisz się upewnić, że nowo wrzucony kod będzie działał na kompatybilnej bazie. Jeśli chcesz żeby Twoja aplikacja zaczęła zapisywać jakieś nowe pole dla modelu, to fajnie jakbyś miał pewność, że kolumna w tabeli będzie istnieć
Tak samo jak odpalenie jednego skryptu na dowolnie skończonej ilości podobnie skonfigurowanych środowisk. Serio nie pamiętam żeby kiedyś był z tym problem zwłaszcza w przypadku DML, DDL iż coś działa na bazie testowej a na produkcyjnej już nie. Składnia się nie zmienia. Myśleć nawet nie trzeba. Jedyną przeszkodą jaką widzę to migracje między RDBMS ale to tylko na poziomie jakiś commitów, a nie sądzę żeby Active Record był w stanie załatwić taką migrację kilkoma kliknięciami.
Dzisiaj po przejrzeniu dokumentacji widzę że niestety Active Record jest totalnie nie intuicyjne. Brak podstawowej logiki. No bo w sumie gdzie w bazie danych występuje jakiś remove_column czy add_column. Wszędzie się robi alter table table_name add (column_name type), alter table table_name drop column_name. Jak i parę innych rzeczy które totalnie nie mieszczą się w standardach sqlowych. Ech trzeba się albo przestawić albo robić to wszystko funkcją w bazie i tyle.
ActiveRecord jest zaprojektowany tak żeby pomóc programistom, tak ogólnie. Nie każdy jest specjalistą od baz danych. W większości ActiveRecord pomaga, czasami przeszkadza. A jak masz wiedzę, to prawie zawsze przeszkadza
Jeżeli ActiveRecord nie przypadł Tobie do gustu, to sprawdź ROMa - http://rom-rb.org może przypadnie tobie do gustu.
Niestety nic do projektu nie dodam, dla mnie AR przeszkadza, bo umiem po pierwsze wersjonować kod, a po drugie umiem to wszystko napisać nawet z palca znacznie szybciej niż ten czas który stracę na zastanawianie się nad nieintuicyjną składnią AR i tym co zepsuje zapuszczenie rake.
No nie bardzo wiem do czego to się odnosi. Tak, im dalej w to idę tym bardziej widzę herezję AR.
Generalnie jest tak że jedno miejsce naprawione w kodzie rozwala dwa inne. Nigdy wcześniej tak nie było, ani w PLSQL, ani w javie. Nawet w js.
Kalaf zapewne miał na myśli, że Twoje narzekanie jest bezcelowe i zalatuje trollowaniem. Szukałeś pomocy, to dostałeś. Nie ma rozwiązań, które wszędzie się sprawdzają.
Nie pasuje Ci AR? Zmień go.
Nie możesz zmienić? Przekonaj innych (dostałeś nawet wyżej alternatywę, jest też kilka innych np. Sequel, który pewnie by Ci najlepiej odpowiadał, mógłbyś nawet jechać z samymi customowymi zapytaniami używając DB.run).
Nie możesz przekonać? Nie utrudniaj życia innym i naucz się (ty może super się czujesz klepiąc czyste SQL, ktoś inny w teamie może zna Railsy i naturalniej jest używać AR). Tak naprawdę AR jest bardzo intuicyjny, jeśli tylko zrozumiesz zasadę działania (hint: implementuje wzorzec… Active Record, są też inne).
