더 이상 이 블로그는 운영되지 않습니다. 새 블로그로 가 주세요.
아래 문제 해결.
2004/11/18 PM 10:22 | 개발/soojung | 6 comments | 0 trackbacks | AllBlog: vote, to pocket
파일 포맷 자체는 안 변화시키지만 이름에 영향을 주는 것이라서 일단 cvs 커밋은 보류한다.
덧. 이 작업 하면서 contents/.referer 날려 먹었다. OTL
덧2. 수정한 부분은 여기서 참고할 수 있다. 오작동할 수 있으므로 필히 백업 받아 둘 것을 권한다.
TrackBack URL: http://sapzil.info/soojung/trackback.php?blogid=205
Comment: 토끼군 (2004/11/18 PM 10:41)
어차피 파일 이름만 바꿔요. -,.-;;; 포맷 자체의 변화는 없으니까 그냥 Category: 필드만 확인해서 이름 바꿔 주는 것만으로도 충분할 겁니다.
그나저나 해쉬 알고리즘 저거 그대로 냅둬도 상관 없을까요? 제가 좋아하는 해쉬 알고리즘이긴 한데 좀 느린 것 같기도 해서... (라고 해 봐야 얼마 하겠냐만은)
Comment: ddt (2004/11/18 PM 10:56)
해쉬 알고리즘은 moniwiki에서 페이지 이름 저장하는 방식으로 해도 좋을 것 같아요. 아니면 이거 그냥 써도 되구요. 전 알고리즘이나 시간에는 별 관심 없어서 =0=;
Comment: 올리버네 (2004/11/18 PM 11:06)
전부터 약간 느리다는 감은 받았는데 그랬었군요.
그런데 1.8초라도 좀 느린편 아닌가요.
파일형식이라면 좀 더 빠를 줄 알았는데..^^;
Comment: 토끼군 (2004/11/19 AM 12:29)
ddt: 그냥 이걸 쓰는 게 카테고리 이름 길어 지거나 하는 경우 더 유리할 듯 합니다. cvs에 올렸습니다.
올리버네: 인덱스가 따로 없고 파일 이름과 내용만 가지고 알아 내는 것이기 때문에 그렇습니다. 인덱스를 만들고 잘 관리만 한다면 사실 0.1초 이하로 나오는 것도 어렵지 않죠. (제가 아주 옛날에 만든 파일 기반 위키가 그랬는데, 대신 각 파일 사이의 연관성이 커서 손으로 고치기 힘듭니다. 제 노트북 서버로 돌리면 파싱까지 0.1~0.2초 걸립니다.) soojung은 그냥 받아 들일 정도의 속도만 나오면 된다고 생각합니다만, 프로파일링 많이 해서 고칠 부분은 고쳐야죠. orz
Comment: ddt (2004/11/19 AM 09:57)
네, 속도 빠르게 한다고 데이터 파일들을 사용자가 편집기로 열었을 때 해석이 안 되는 건 반대하는 입장입니다 :)
Comment: ddt (2004/11/18 PM 10:37)
음 좋군요~ 0.4에 집어 넣죠 :)
그런데 0.3.2 데이터 0.4용으로 바꿔주는 것도 만들어 주셔야 해요~ 흐흐