릴리스 0.4: 미완성 작업

만료된 유효하지 않은 키를 확인하기 위해 ttl을 구현하십시오.

구현은 생각보다 아주 간단합니다. 먼저 src/api/posts/src/storage.js에 와서 간단한 변경 사항을 추가합니다.

setInvalidFeed: (id, reason) => {
    const key = createInvalidFeedKey(id);
    const expireAfter = 60 * 60 * 24 * 7; // Expire after 7 days
    return redis.set(key, reason, 'EX', expireAfter);
  },

그러나 테스트는 약간 까다로울 것입니다. 먼저 모든 이미지를 다시 시작하고 cd를 src\backend로 실행하고 npm start를 실행합니다. Emily와 이야기를 나눈 후 우분투에 와서 다음을 입력합니다.sudo docker exec -it redis sh 및 redis-cli를 사용하면 명령을 사용하여 redis 데이터와 상호 작용할 수 있습니다. invalid를 사용하여 keys *invalid 키를 검색하고 임의의 키ttl key를 선택했지만 결과는 doc보다 선호하는 -1을 반환했습니다.

The command returns -1 if the key exists but has no associated expire

따라서 분명히 변경 사항이 작동하지 않았거나 내 예측은 내 변경 사항이 적용될 새 잘못된 피드가 나타날 때까지 기다려야 하지만 오랜 시간 기다린 후에 모든 데이터를 삭제할 수 있음을 regconize합니다. . 나는 내 프로젝트에 들어왔고rm -f redis-data 그 후 내 프로젝트가 작동을 멈추고 프로젝트 관리자에게 친절하게 redis-data 폴더를 다시 보내달라고 요청해야 합니다.

그 후 flushall에서 redis-cli를 사용하여 유효하지 않은 키를 모두 지우고 프로젝트를 다시 실행한 후 사용할 수 있음을 알게 되었습니다. 내 변경 사항은 분명히 전혀 작동하지 않았습니다.

Emily와 이야기를 나눈 후 그녀는 또한 src/backend/utils/storage.js에 와서 동일한 코드 줄을 변경하라고 제안합니다. 프로젝트의 서로 다른 두 위치에 두 개의 동일한 코드가 있지만 변경으로 인해 작업이 수행되는 것이 나에게는 놀라운 것 같습니다.



경험이 더 많은 Slack 채널의 일부 사람들과 이야기를 나눈 후. 친절하게 설명해주셨어요

that's because initially we had only one back-end (the one inside the backend folder) doing everything, and as we started developing microservices, we had to move the code to the microservices using that code. The easiest way was to copy the whole chunk of code from the old backend to the microservice you're working on, but sometimes you might copy parts that you don't need, like setInvalidFeed in this case

이것은 프로젝트에 대한 내 지식 때문에 아직 이해가 되지 않지만 기능 기본 설정을 위해 여기에 메모하겠습니다.

내 PR를 확인할 수 있습니다.

Git을 사용할 때 배우는 또 다른 트릭

Duke와 대화하고 작업할 때 우리는 작업을 위해 Gitpod를 사용하고 협력하려고 노력하므로 브랜치dummy에서 얻은 것의 issue-2569 버전을 업로드하지만 두 번째 요구 사항을 해낼 수 없었기 때문에 PR을 제출해야 합니다. 나는 프로젝트에 들어가서 git reset --soft를 사용하고 MOCK_REDIS =의 변경 사항과 proccesor.js의 변경 사항을 버리고 push -f 다시 분기로 보냅니다.

이제 14주가 지난 지금 git에 조금 익숙해지고 흐름을 이해했다고 말할 수 있습니다!