게시판 정렬에서 list_order 와 regdate 를 다시 분리하는건 어떤지요?

[sejin7940]

과거 XE 업데이트시 두가지 통합이 #384 에서 받아들여졌는데
최근 http://www.xpressengine.com/forum/22734036 에 관련 문의가 다시 있고.
패치 인정된것도 다시 번복될 수 있는 거니까..
다시한번 논의대상으로 끄집어내어볼까합니다.

일반적으로는 list_order 와 regdate 가 거의 같은 순서로 사용이 되긴합니다.
그런데 이 두가지는 엄밀히 말해 다른 개념이죠
특히나 XE 로 유료회원제 사이트를 만들경우 이 개념의 분리가 필요한 경우가 있습니다

쉬운예로, '글 올리기' 기능 같은 것들이죠
유저들이 이용권으로 글을 올리든, 모듈기반으로 하루 몇회 자동올리기든..
글을 상단으로 끌어올리는 방법이..

list_order 값을 변경시키는 방법을 통해 구현했었습니다
(해당글이 등록된 날짜는 유지되어야하기에 regdate 를 변경시킬 순 없고. 최근 등록된 글을 보기 위해 regdate 기준으로 정렬해야할 때도 있거든요)
(정렬을 last_update 로 했다간, 글 수정이나 댓글등록시 변경되기에 이도 사용할 수가 없죠)

그리고 확인해보니 두가지를 분리해야하는 더 큰 이유가 있네요.

document_srl 과 list_order 는 원칙적으로는, 글이 실제 등록되는 시점에 발생하지만..

예외적으로 파일첨부가 있는 경우, 파일첨부 눌러 첫번째 파일이 첨부되는 순간
임시저장이 자동으로 되면서 이 때 document_srl 값 (정확히는 file 쪽의 target_srl) 이 생성되는군요
이 파일첨부된 자료가 정상 등록되면, target_srl 이 document_srl 이 되는거고.. 이 음수가 list_order 가 되죠.

결국, 누군가가 파일첨부를 먼저 한 후..
다른 사람이 글을 실제 등록하고..
파일첨부 했던 사람이 본문내용쓴다고 늦게 등록버튼을 누르면

list_order 순서대로 (현재는 이게 등록순으로 나오죠) 로는 글이 역전되어버리는 현상이 생기는군요
regdate 로는 실제 등록순서대로 나오게 되고..

즉, 사진첨부가 많은 사이트에서는 list_order 가 아니라 regdate 로 해야 실제적으로는 맞는거고
결국 현재 regdate 를 없애버린게, 버그가 되어버리는 꼴이 됩니다.

결국, list_order 와 regdate 는 각각 다른 방식으로 유용한 의미가 있는 정렬법이었는데
기본 정렬에 regdate 개념이 사라져버렸군요.

list_order 와, regdate 를 다시 예전처럼 분리해야 맞는 듯합니다.

[largeden]

@sejin7940

이 이슈는 제가 관여했던 부분인지라 소트 방법에 regdate를 왜 제외했는지의 근거와 고민하시는 내용의 해결책을 제시해야할거 같아서 의견을 달아봅니다.

우선 참고사항으로써 제가 이슈를 제시한 과정을 아래에 링크해놓겠습니다.

#375 [1.7.4 beta] board의 게시물 정렬 컬럼에 대해
#384 게시판 정렬 기준 컬럼 변경 regdate -> list_order
#393 [의견] list_order, update_order 인덱스 힌트 사용 구문은 제거가 필요
#399 [1.7.4 beta] content 위젯에도 regdate 정렬이..
http://www.xpressengine.com/forum/22586306 XE DB 튜닝하기

근거

위에 나열해놓은 내용대로 조사와 시뮬레이션을 거쳐본 결과 regdate, last_update 정렬방식은 성능에 효율적이지 못하였습니다. XE 구조상 regdate, last_update의 정렬은 list_order, update_order가 대신 정렬하는 역할을 하고 있으며 idx_module_list_order, idx_module_update_order로 인덱스 또한 만들어져있는 구조 입니다.

현재, 또는 향후에 대용량의 정보를 다루게 될때 XE의 구조문제로 성능에 영향이 갈 수 있기 때문에 의견을 제시했고 XE 개발팀에서 고민끝에 커밋을 한게 아닌가 싶습니다.

문제점

말씀하신데로 서드파티 개발 문제와 몇몇 특수한 처리 방법에서 regdate와 list_order 처리에는 모순이 있습니다. 하지만 그렇다고하여 XE 성능개선을 포기하면서까지 기존의 정렬 방법으로 돌아가는 것은 바람직하지 못하다는 입장입니다. 성능을 지키돼 모순을 개선하는 노력을 해야한다는 생각입니다.

해결책

첫번째, 서드파티 모듈의 경우는 코어가 개선되면 그에 따라 버전업을 해야한다고 생각합니다. 물론 많은 서드파티 모듈에서 똑같이 호환성문제가 있다면 그것은 코어단에서 어느정도 조율을 할 필요는 있으나, 몇몇의 서드파티 모듈이 문제라면 그것은 개발자가 버전업을 시켜서 최신 버전에 대응해야한다는 생각입니다.

두번째, 첨부파일 등록 과정에서 발생되는 모순에 대해서는 저도 문제점이라고 생각합니다. 하여, 아래와 같이 개선하면 어떨까 의견제시해 봅니다. 첨부파일이란게 upload_target_srl를 획득하기 위함인데 실제로 autosave라는 동작과도 맞물려 있습니다. 그리고 autosave와 비슷하게 임시저장(TEMP)이라는 기능도 있습니다.

xe_editor_autosave로 저장되어있는 경우와,
xe_documents에 temp로 저장되어있는 경우의 list_order, regdate 대응방식이 좀 다릅니다.

#board.controller.php
/**
 * @brief insert document
 **/
function procBoardInsertDocument()
{
//...
        // modify list_order if document status is temp
        if($oDocument->get('status') == 'TEMP')
        {
            $obj->last_update = $obj->regdate = date('YmdHis');
            $obj->update_order = $obj->list_order = (getNextSequence() * -1);
        }

//...
}

보시면 아시겠지만 temp처리가 되어있는 상태에서 최종 저장을 할 경우 list_order, update_order, regdate, last_update를 최신값으로 재부여하고 있습니다. 저는 이 방식을 autosave에도 도입하면 좋겠다고 생각합니다. sequence가 두번 더 낭비되는 점에 있어서는 좋은 방법이 아닐 수도 있습니다. 성능이 떨어지는 regdate 정렬로 회유하느냐 sequence를 조금 더 사용하더라도 최상의 성능을 유지하느냐, 저는 XE 개발팀의 선택에 맡기겠습니다.

덧 : 이 이슈가 롤백되더라도 저는 전혀 서운해 하거나 하지 않습니다.
(벼 별로.. 큐브가 갖고싶어서 이러는게 아니라능...;;)

[bjrambo]

@largeden 롤백과 동시에 큐브반납하라고 하면../하앍..잡담../

한가지 질문점이 있습니다. 제시해준 코드에서 직접적으로 sequence 를 조금 더 사용하되 최상의 성능을 유지 하느냐 이러한 내용에 의문이 있습니다.

과연 regdate 를 사용하는 것에 걸리는 성능과 sequence 으로 걸리는 성능저하 둘중에 오히려 훨신 저하가 심해지는 것이 regdate라는 것인데.. 사실 제가 확인했을 때 무엇때문인지.. 이해가 잘 안갑니다.

그 것에 대한 설명을 들어볼 수 있을까요?

[sejin7940]

@qw5414
asc 가 desc 보다 빠를거예요.. 그래서 list_order 가 음수로 되어있죠.

@largeden
제 생각에는 용어의 혼란 (어쩔 수 없는 부분인듯 싶지만) 때문에 합쳐진듯 싶어요
'문서번호' 라는 용어 자체가 어색하니.. (게다가 XE 는 실제로는 문서번호가 없으니..)
그리고 그냥 보면, 이 문서번호 와 등록일 개념의 차이도 애매하고. 이용자 입장에서 괜히 어려우니
쉬운 '등록일' 이라는 용어와, 속도가 빠른 'list_order' 를 합쳐버린게 아닌가 싶습니다.

'문서번호' 라는 용어보다 더 적합한게 있으면 좋을듯한데, 저도 떠오르는게 없다는 ^^;

[largeden]

@qw5414
제가 링크걸어놓은 내용은 다 참고하셨는지요? XE DB 튜닝하기 끝부분에 regdate와 list_order에 대해 내용이 있습니다. 그리고 sequence 때문에 성능저하는 없을거 같은데요? 번호 낭비는 있을 순 있어도요.. 설령 저하가 있다 하더라도 조회와 글 등록의 빈도를 생각해보면 어디가 더 병목이 많을지 알 수 있을거라고 봅니다만..

@sejin7940
마찬가지로 위에 적어놓은 내용에 용어에 대한거라든가 의견이 달려있습니다. 그리고, list_order문제는 이 이슈가 커밋되기 이전부터 있었다는걸로 인지되기 때문에 롤백되든 안되든 해결 해야할 문제라고 생각합니다.

[bjrambo]

@largeden 정독을 해봤지만..이해 잘안되어서용 ㅎㅎ

아무튼 좋은 대안으로 갈수 있다면.. 좋은거지요 :) 항상 감사해용 :)

[akasima]

@sejin7940 @largeden
list_order 와 regdate를 분리 했습니다.
#384 의 수정 내용이 정렬 순서의 변경을 통해서 기능개선을 한다기 보다는 regdate 정렬을 제거 하는 역할만 하게 된것 같습니다. list_order 와 regdate를 기존 처럼 사용자가 선택적으로 사용 할 수 있도록 롤백하는게 맞다고 판단 되었습니다.

단 #384에서 last_update 수정에 관한 논의는 없었으므로 update_order를 이용해서 정렬하는 변경사항은 유지하도록 하겠습니다.

@largeden 님이 작성해 주신 list_order 와 관련된 여러 이슈들은 XE Core의 버그들이 어느정도 수정되면 논의 될 수 있을거라 생각합니다.