DataGrip에서 소스 코드로 작업
목차
기본 사항
객체의 소스 코드는 객체를 생성하는 데 필요한 DDL 스크립트의 핵심적인 부분입니다. 즉, CREATE 문은 객체 소스 코드의 일부가 아니며 소스 코드는 데이터베이스 내부에 저장됩니다. 소스 코드의 가장 일반적인 객체는 뷰, 함수 및 저장된 프로시저입니다.
다른 많은 도구에서는 소스 코드를 업데이트하려면 CREATE OR REPLACE 스크립트를 생성한 후 필요한 변경을 적용하고 스크립트를 실행해야 합니다. DataGrip에서 소스 코드 변경 방식은 조금 다릅니다. 필요한 변경을 적용하면 적절한 스크립트가 생성됩니다.
다른 도구를 사용하던 분들은 모두 동일한 실수를 합니다. DDL을 열고, 복사, 수정 후 <0>CREATE 구문을 변경(일반적으로 <0>OR REPLACE 추가)하고 새 스크립트를 실행하는 것입니다.이는 소스 코드 업데이트에 적합한 방식이 아닙니다.
소스 로드
DataGrip은 모든 데이터 소스에 대해 ‘내부 검사(introspection)’라는 프로세스를 수행하여, IDE에서 미리 객체의 모든 메타데이터를 미리 불러옵니다. 즉, 내부 검사 수행 시 모든 소스 코드가 로드됩니다.
데이터 소스 프로퍼티의 Load Sources for(다음에 대한 소스 로드) 옵션에 필요한 값을 선택하면 이 프로세스를 관리할 수 있습니다.
Oracle에서는 내부 검사 수준을 더 낮게 선택하여 소스를 로드하지 않을 수도 있습니다.
‘내부 검사 수행 시 소스 코드가 로드된다면, 오래된 것이 아닌가?’하는 의문이 들 수 있습니다.
오래된 것이 맞습니다. 이 상황을 처리하는 방법은 튜토리얼의 뒷부분에서 설명해 드리겠습니다.
흐름
데이터베이스 탐색기에서 객체를 두 번 클릭하거나 SQL 스크립트에서 Cmd/Ctrl+B를 누르면 DDL 에디터가 열립니다. 또한 데이터베이스 탐색기에서 뷰를 더블 클릭하면 데이터가 열립니다. DDL 탐색기를 열려면 툴바의 DDL 버튼을 클릭하세요.
DDL 에디터가 열리면 객체의 CREATE 스크립트를 찾을 수 있습니다.
중요 사항! 생성된 스크립트의 객체 참조가 한정되지 않았습니다. 즉, %schema_name%.%view_name% 대신 %view_name%이 사용됩니다. 그 이유는 스크립트를 복사하여 다른 컨텍스트에 적용할 수 있기 때문입니다. 참조가 한정된 스크립트를 원하는 경우 SQL 제너레이터를 사용하세요.
DDL 에디터에서 소스 코드를 변경할 수 있습니다. 객체 소스 코드 편집 시 DataGrip은 변경 사항을 추적하고 여백에 강조 표시합니다.
예를 들어, 프로시저나 함수에 줄 주석을 추가하면 추가된 줄이 강조 표시됩니다. 여백에서 강조 표시된 줄을 클릭하면 Show Diff(Diff 표시) 버튼과 함께 작은 툴바가 표시됩니다. Show Diff 버튼을 클릭하여 추가된 코드와 소스 코드의 차이점을 확인할 수 있습니다.
필요한 변경 사항을 적용하고 Submit(제출) 버튼을 클릭합니다.
DataGrip에서 수정된 스크립트를 생성하여 미리보기를 표시합니다.
결과가 만족스러운 경우 OK를 클릭하면 데이터베이스에서 스크립트가 실행됩니다. 결과적으로, 필요한 소스 코드가 변경됩니다.
DataGrip은 생성 스크립트에 OR REPLACE를 추가할 뿐 아니라 객체 시그니처 변경 또는 객체 이름 변경 등 더 까다로운 작업도 처리할 수 있습니다. 필요한 경우 DROP 및 CREATE 스크립트가 생성됩니다.
한 번에 여러 객체 변경
DDL 에디터에 변경 사항이 있으나 아직 제출되지 않은 경우, DataGrip은 제출 시까지 해당 변경 사항을 저장합니다. 예를 들어, 여러 객체를 변경하면 변경된 여러 DDL은 캐시되어 적용될 때까지 보류됩니다. Database Changes(데이터베이스 변경)라는 도구 창에서 보류 중인 소스 코드의 변경 사항을 모두 확인하고 한 번에 제출할 수 있습니다.
오래된 캐시된 객체
앞서 언급된 바와 같이 DataGrip은 내부 검사에서 로드된 소스 코드를 캐시합니다. 열었던 객체가 타사 위치에서 업데이트된 객체인 경우 캐시된 객체 및 데이터베이스에 있는 동일 객체의 소스 코드 간 차이점이 있다는 알림이 표시됩니다.
IDE에 이 경고가 표시되면 다음 작업 중 하나를 선택하여 수행할 수 있습니다.
- Synchronize(동기화): 데이터베이스에서 변경 사항을 가져오고 캐시된 로컬 객체를 업데이트합니다.
- Disable check(검사 비활성화): 알림을 비활성화합니다.
또한 객체 소스 코드의 버전과 데이터베이스 버전 간 충돌이 발생할 수 있습니다. 예를 들어, 다른 사람과 동일한 소스 코드를 수정하고 Submit(제출)을 클릭한 경우 충돌이 발생합니다.
이러한 경우 Force Refactoring(리팩터링 강제 실행)을 사용하여 데이터베이스에 있는 객체의 소스 코드를 강제로 대체하거나 객체 상태를 동기화한 후 Abort Refactoring and Synchronize(리팩터링 중단 및 동기화)를 클릭하여 변경을 진행할 수 있습니다.
Abort Refactoring and Synchronize(리팩터링 중단 및 동기화) 옵션을 선택한 경우 DataGrip은 제출 작업을 중단하고 Synchronize(동기화) 옵션을 클릭한 경우와 마찬가지로 데이터베이스에서 변경 사항을 가져옵니다. 충돌이 지속되는 경우 다음 알림이 표시됩니다.
해당 알림에서 다음 옵션 중 하나를 선택할 수 있습니다.
- Revert local changes(로컬 변경 내용 되돌리기): 모든 변경 사항을 되돌리고 데이터베이스의 버전으로 바꿉니다.
- Keep local changes(로컬 변경 내용 유지): 변경된 내용을 사용하고 데이터베이스의 변경 사항을 덮어씁니다.
- Merge(병합): 객체 소스 코드의 버전을 병합하기 위해 Diff 대화상자가 표시됩니다.
로컬 기록
소스 코드의 모든 변경 사항은 로컬에 저장됩니다. 시간을 되돌려 최신 업데이트 전 함수의 소스 코드를 검사하려는 경우 Local History(로컬 기록)을 활용하면 좋습니다.
Local History의 리비전에는 모든 로컬 변경 사항이 포함되며, 내부 검사 중 데이터베이스에서 불러온 버전도 포함됩니다. 따라서 내부 검사 중 ‘로드’되지 않고 타사 소스에서 가져온 객체 버전은 누락되었을 수 있습니다. 과거의 모든 리비전을 소스 코드의 현재 버전과 비교할 수 있습니다.
특정 데이터베이스에서 작업하는 사용자가 본인 한 명이고 DataGrip에서만 소스를 변경하는 경우, Local History에서 객체 변경과 관련한 전체 기록을 확인할 수 있습니다.
이상입니다! 특히 다른 도구를 사용하던 경우 이와 같은 흐름이 낯설게 느껴질 수 있습니다. 하지만 이 흐름을 따르면 반복 작업이 제거되어 한층 편리합니다.
DataGrip 팀 드림
추신: 스크린샷에 사용된 색 구성표는 Monocai입니다.
게시물 원문 작성자
Subscribe to DataGrip Blog updates
