Tag Test2

j10k·2018년 11월 7일
0

가설 구체화
하나의 글에 여러개의 tag를 동시에 넣고 tag 클릭 시 마다 글들을 찾아주려면
DB에 text_id, tag 1:n 매칭관계
지금 글에 tag를 등록하고 생성하자마자 tag의 대소문자가 바뀜.
왜 생성하자마자 바뀌었을까?
POST 요청이 들어오면 글의 정보를 DB에 넣을 텐데 DB에 넣을 때 까지는 대소문자가 유지되어 있었을 것임.
DB에 넣으면서 바꿀 일이 있을까?
글이 업데이트되어 하단에 tag list를 view로 뿌리는 과정에서, 다시 DB에서 text_id의 tag를 로드하겠지?
아닌가 DB까지 굳이 가지 않고 tag list 정보가 남아 있나?
여튼 글 POST가 완료된 후 tag를 눌렀을 때 해당 tag를 갖는 text list를 보여줘야 하므로
1) DB에서 가져온다면
text_id에 연결된 tag를 모두 로드. 이 과정에서 collation이 case-insensitive 하다면 대소문자가 다른 두 개의 태그를 다 불러오지 않고 동일시하여 하나만 불러옴. 이것이 하단의 아이콘에 이름과 url도 붙으므로 가설이 재현 가능한 상황
2) DB에서 굳이 다시 불러온게 아니라 정보가 남아있었다면
대소문자 구별된 string 정보가 그대로 작성된 글 아래에 뿌려졌을 텐데 그게 아님. toupper나 tolower도 아니므로 의도한 상황이 아니고야 설명이 안됨.
extra) 의도한 것이라면?
대소문자 구별된 string list를 갖고, 특정 함수를 불러서 toupper 등을 하여 같은 tag가 있다면 그 tag의 이름과 동기화 시키는 로직을 삽입한 것이라면. 왜 굳이 맨처음 tag와 동기화인가? 글 POST시에는 대소문자가 유지된 tag를 보여주고 링크를 누르면 insensitve 로직으로 해당 tag의 나머지 글들을 찾아주면 될텐데. 어쨌든 이 부분은 빼먹었지만 tag 대소문자 구별없이 통일화가 의도한 것이라면, 심지어 최초에 DB에 저장도 동기화를 하며 저장한다면? case-sensitive collation인데 일부러 동기화를 한 것이라면? 해당 tag명으로 db에서 insensitive하게 검색한 후 나온 tag list의 맨 처음 값으로 전부 동기화 한 것이라면?
잠시만, 만약 collation에 의한 것이라면, 최초가 아니라 collation rule에 따른 winner 가 나와야 할텐데 항상 최초라는건? 가설이 틀렸나?

3개의 댓글

comment-user-thumbnail
2018년 11월 7일

의도한 것이라면?

  1. TOUPPER, TOLOWER 를 사용하지 않았던것은 퍼포먼스 이슈가 있었기 때문인데, 인덱스가 제대로 작동하지 않기 때문입니다. 물론 현재 PostgreSQL 에서는 Indexes on Expressions 를 지원합니다만 이 프로젝트가 처음엔 CockroachDB 를 사용하여 개발하고 있었는데 이 DB 는 Indexes on Expressions 가 작동하지 않았습니다 :0 링크

  2. 단순히, 대소문자가 유지된 태그를 등록시키게 된다면 발생 할 수 있는점은 태그를 리스팅 할 때 번거로워진다는 점 입니다. Tag, tag, taG 가 따로따로 나타나게 되겠죠. 다 같이 조회는 된다고 해도.. 태그를 리스팅할때는 또 따로 처리를 하지 않는이상 다른 대소문자로 여러개의 태그가 보여질수있는 가능성이 있습니다.

  3. 무조건 최초의 데이터가 우선권을 가지게 하려는것은 아닙니다. 이 기능을 만들게 될 때 나중에는 "더 많이 사용되는것을 우선권을 가지게 하자" 라는 계획으로, 기존거랑 틀린것이 더 자주 발생하면 값을 교체하는것도 생각해뒀으며.. 혹은 alias 기능을 통해서, 보여지는건 사용자가 입력한거 그대로 보여주는데, 그대신에 실제로 가르키는건 다른태그이게끔, 구현하는것도 생각을 해봤습니다.. :-) 하지만 이에 대한것을 구현하는건 좀 나중 일 일것 같습니다!

ㅋㅋㅋ 서비스 시스템에 관심가져주셔서 감사합니다~

2개의 답글