내 데이터베이스의 관계를 has_many에서 has_many : through로 변경하고 있습니다. 지금 당장 가지고 있습니다.db : migrate를 통해 구조적 db 변경 후 데이터 업데이트를 수행하는 레일스 방법은 무엇입니까?
class Brand < Ar::Base
has_many :products
end
class Product < AR::Base
belongs_to :brand
end
그리고 조인 테이블을 추가 할 것입니다.
물론 데이터베이스를 데이터로 업데이트해야합니다. 나는 이주의 경계에서 이것을하는 것이 좋은 습관이 아니라는 것을 알았다. 이 작업을 수행 할 수있는 가장 좋은 장소는 어디입니까? 데이터 업데이트가 완료된 후 (예 : 제품 표에서 원래 brand_id 열을 제거한 후) 다른 이전을 실행해야한다는 것을 알고 있습니까?
질문을 오해하지 않는 한, 이전은 해당 변환을 수행 할 장소입니다. 마이그레이션의 목적은 스키마를 변경하고 기존 데이터를 마이그레이션하여 스키마를 사용하는 것입니다. 마이그레이션은 스키마 변경을 계층화하는 일시적인 측면을 포착하므로 일관성없는 상태로 데이터를 남기지 않고 시간을 앞뒤로 이동할 수 있습니다. 행을 다른 곳으로 이주하려는 경우, 해당 코드가 실행될 때 스키마가 이주 코드를 작성한 시점과 동일하다는 보장은 없습니다.
Active Record Migrations API 문서의 예에서 내 입장을지지한다고 생각합니다. db/seeds.rb에서 처리되는 시드 데이터 (rake db:seed)를 채우는 것과 혼동을 줄 수 있습니다.
데이터 조작 직후에 2 차 마이 그 레이션을 실행해야하므로 마이 그 레이션 내에서 데이터 조작을 실행하는 코드 (아마 레이크 태스크)에 대한 호출을 포함시켜야한다고 생각합니다.
나라면 데이터를 조작하는 레이크 작업을 만들 것입니다. 이렇게하면 최소한 마이그레이션에서 코드가 제거되고 필요한 경우 수동으로 실행할 수 있습니다. 그런 다음 마이그레이션을 코딩하고 해당 레이크 작업에 대한 호출을 포함시킵니다. 솔직히 말해서 마이 그 레이션에서 데이터 조작을 사용하지 않는다는 것이 큰 의미는 아닌 것 같습니다. 특히 당신이하고있는 특정 순서대로 일을해야 할 때. 그들은 너무 가깝게 묶여 있으므로 왜 완전히 분리합니까?
동의합니다. 스키마로 데이터를 마이그레이션하는 예약을 이해할 수 없습니다. 내 이해를 위해 이것은 마이그레이션의 목적입니다. 왜 당신은 하나의 커밋 내 매우 정확한 순간에만 적용 할 수있는 레이크 태스크를 코드베이스에 넣고 싶습니까? –
의견을 제쳐두고, 마이그레이션 내에서 데이터를 건드리지 않으려면 레이크 작업이 적절한 수단이라는 데 동의 할 것입니다. –
데이터 조작이이 특정 마이그레이션에만 적용된다는 것이 중요합니다. 이 경우 레이크 작업이 다른 시간에 사용되지는 않습니다. – johnmcaliley
이와 같은 일회성 변경은 이전시 루비 코드를 사용하여 수행 할 수 있습니다. 마이그레이션은 스키마 변경에만 국한되지 않습니다. 버전/날짜 코드에 따른 마이그레이션은 한 번만 실행되도록 보장됩니다.
그는 마이 그 레이션 (조인 테이블 추가)을 실행 한 다음 테이블의 데이터를 조작하고 그 후에 다른 마이 그 레이션을 실행하는 것처럼 보입니다. 초기 데이터를 시드하기 위해 씨앗이 추가되었지만 이는 그가 달성하고자하는 것이 아닙니다 ... 그는 기존 데이터를 조작하려고합니다. 어떤 이들은 당신이 단지 테이블 자체의 마이그레이션으로 테이블의 데이터를 조작하면 안된다고 주장합니다. – johnmcaliley
이 작업을 수행 할 올바른 위치는 단일 마이그레이션에 있다고 주장합니다. 첫 번째 마이 그 레이션과 관련된 변경 사항을 실행하고 데이터를 마이 그 레이션 한 다음 나머지 변경 사항을 실행합니다. 3 단계가 결합되어 임의로 독립적으로 실행해서는 안되며 하나의 마이그레이션 내에 포함되어야합니다. –
동의합니다. 데이터 조작을 별도의 루비 파일이나 레이크 작업으로 옮길 수도 있습니다. – johnmcaliley