PHP는 Xdebug라는 강력한 툴을 제공한다. 그런데 이거 초반에 많이 헤맸다. 로컬에서는 아무 문제가 없다.
내 경우엔 윈도우에 php를 직접 설치하여 개발을 하지 못했다. PHP버전때문. 회사 프로젝트의 php버전이 낮아 최신 버전을 사용할 수 없었다. 그래서 도커로 예전 버전 이미지를 사용하여 개발을 할 수밖에 없었다. 오히려 이게 깔끔하다. 그런데 이렇게 하니 디버깅을 어떻게 해야 할지 난감했다.
그렇지만 방법을 찾았다.
나는 vscode를 사용하여 개발한다. 여기에 remote explorer 확장이 있다. 이걸로 해당 서버에 원격으로 접속할 수 있다. 그리고 미리 준비된 xdebug가 포함된 php 서버이미지를 사용하여 프로젝트를 시작한다. 라라벨은 이미 준비되어있다.
remote explorer의 Dev Containers에 해당 컨테이너를 선택하여 진입하고 Explorer에서 Open Folder를 선택하여 프로젝트 폴더를 선택한다.
이런 유사한 화면이 나올것이다. 여기서 프로젝트 폴더를 선택한다. 라라벨에선 /var/www/html이다.
그리고 xdebug 설정을 한다.
xdebug_mode는 develop, client_host는 localhost로 했다. idekey=docker는 phpstorm에서 사용한다던데 써본적이 없어 잘 모르겠다.
vscode의 디버깅 툴(Run and Debug)을 사용하자. 처음엔 어떤 디버깅 툴을 사용하려고 하는지 선택하라고 나오는데 PHP를 선택하자.
톱니바퀴 모양을 누르면 launch.json을 만들어줄거다. 자동으로 만들어준다. 설정은 바꾸지 않아도 된다.
이제 저 play버튼을 누르면 서버의 debug port와 연결한다. 이제부터 소스에 브레이크포인트를지정하여 디버깅을 할 수 있다.
입력하기는 해당 데이터를 추가하고 추가된 내용을 화면에 출력하기만 하면 된다. 그런데 수정하기는 좀더 복잡한 과정을 거쳐서 수정을 해야 한다. 누가 입력했는지 어떤걸 입력했는지 확인해야 한다. 그러려면 사용자도 있어야 하고 로그인 기능도 있어야 한다.
먼저 로그인 및 사용자는 Laravel/Bleeze를 사용하고 있다. 그리고 Laravel은 기본적으로 Schema에 timestamps 하나로 created_at과 updated_at을 제공한다.
edited라는 표시를 어떻게 하나 봤더니 created_at과 updated_at이 다르면 표시하게 되어있었다. 그간 나는 updated_at에는 null인 상태, 그러니까 아무것도 입력하지 않은 상태로 유지하고 update가 발생할 경우 입력하여 일시를 기록했는데 최초에 updated_at을 created_at과 함께 입력하여 null을 방지하였을거라 추측한다. 이게 더 합리적이네.
날짜, 시간별로 파일명이 생성된다는건 그렇게 관리 할 수 있다는 말과도 같다. 그러니 이를 어떻게 관리하는지 찾아보자. 내가 이상하게 생각하는건 django에서는 모델의 설정이 따로 있고 마이그레이션 파일이 있어서 모델의 컬럼설정을 자동으로 마이그레이션 파일로 생성해주었다. 그런데 라라벨에서는 모델과 마이그레이션 파일이 별도로 움직이는듯한 느낌을 받았다.
데이터베이스 스키마를 모두 마이그레이션에서 한다. 모델은 fillable이라 해서 사용자의 입력을 받는 곳을 지정한다. artisan으로 모델을 생성할 때 마이그레이션 파일도 같이 생성되고 이때 id, created_at, updated_at, user_id 같이 데이터의 관리를 위한 칼럼이 자동으로 추가된다.
그렇다면 마이그레이션을 이렇게 밖에 할 수 없을까? 뭔가 다른 방법이 있을거 같은데?
마이그레이션 방법
php artisan make:migration create_flights_table
실행하면 현재일시로 기본상태(id, timestamp)만 가진체 마이그레이션 파일이 생성된다. 그런데 내가 원한건 현재상태(기존 칼럼을 그대로 가진)의 마이그레이션 파일이다. 좀더 알아보니 같은 테이블을 마이그레이션 하는데에는 좀더 신경써야할 부분들이 있었다.
최초에 테이블을 생성하면 위 그림과 같이 id와 timestamps가 생성된다. 그리고 내가 추가하고 싶은 칼럼을 추가한다. 이렇게 사용하다가 추가 칼럼이 필요하면 새로 마이그레이션을 생성한다. 그리고 나서 create가 아닌 “Schema::table(‘table_name’, function(Blueprint $table){” 형태로 해서 추가 칼럼을 등록한다.
부트캠프의 Chirps 까지 진행을 했다. 그래서 화면에 Hello, World! 까지는 출력을 했다. View를 달아준다.
Vite Development 덕분에 (npm run dev) 리로드를 하지 않아도 코드 수정후 저장만 하면 즉각 변경을 해준다.
적당히 적용해주면 이렇게 화면이 나온다. 그러니까 index.blade.php는 본문역할인샘.
상단 네이게이션도 레이아웃에 별도로 추가할 수 있어 여기에 코드를 추가하면 서로 연동할 수 있다. 참 잘 만들어 놨다. 물론 여기에 맞춰 만들면 그런데 이 틀을 벗어나려면 고생을 좀 해야겠지?
그리고 다음에 할 건 사용자가 Chirps를 등록함에 있어 HasMany 관계를 맺는다. 스프링의 JPA는 양방향으로 관계를 맺을 수 있어 Many to One 또는 One to Many를 할 수 있다. 이 케이스에서는 User에 One to Many를 한다. 내 경우엔 Chirps에 Many to One을 하는게 데이터 모델링 측면에서 더 어울린다 생각했다. 여기선 HasMany로 이루어진다니 이부분은 좀더 알아봐야겠다.
컬럼 설정
validation은 컨트롤러에 있다. 모델에는 없고. 그런데 실제 DB의 테이블 컬럼에 적용되었다. 이렇게 추측한 이유는 validation에 ‘message’ => ‘required|string|max:255’, 때문.
그런데 저 값을 변경하고 migrate:fresh를 했는데 디비에 적용되지 않았다. 왜지? 혹시나 싶어 컬럼을 삭제후 다시 migrate를 했으나 255그대로이다. 이건 기본값이 255인가보다. 그렇다면 validation을 컨트롤러에서 하는 추측은 맞지 않는다.
컬럼 설정은 Migration에서 한다.
이렇게 length를 지정할 수 있었다.
Migration 파일의 관리
Migration 파일은 각 모델마다 database\migrations\yyyy_mm_dd_hhiiss_create_(model_name)_table.php 형태로 생성된다. 왠지 모델을 변경할 때마다.migration 형태로 생성되는거 같은데 지금은 수동으로 해당 파일을 만지고 있다. 다른 방법이 있는지 찾아보자.
구조 자체는 코드이그나이터랑 비슷한거 같다. 그럼에도 라라벨만의 특징이 있겠지. 설명만 봐선 잘 이해가 안간다. 한 번 사용을 해 보면서 어떤 구조인지 파악하는 과정이 필요하다. 의존성 주입도 있고 해서 마치 스프링부트 같기도 하고.
부트캠프
라라벨은 부트캠프를 제공하고 있었다. 한번 따라 해보자.
우분투의 경우 설치 과정에서 extension을 추가로 설치 해줘야 한다. php-xml, php-curl 을 설치해주자. env는 code를 실행하여 수정해주자.
막히는 중
The stream or file "/var/www/html/storage/logs/laravel.log" could not be opened in append mode: Failed to open stream: Permission denied The exception occurred while attempting to log: The stream or file "/var/www/html/storage/logs/laravel.log"
권한 문제인데 storage에 있는 logs의 권한이 root 인데 php는 sail로 실행하고 있어서 로그를 저장할 수 없다. 해당 디렉토리의 권한을 변경하거나 사용자그룹을 변경하면 되긴 하는데 이게 맞는건지 모르겠다. 좀더 조사중.