1 inureyes이 작성한 주제

  • 지역 대한민국 > 포항
  • 가입일자 2006-04-03
  • 글: 4,471

주제: 1.0.5 의 발표 일정에 관하여

제목보고 '1.0.5의 발표 일정에 무슨 일이?' 하실 분들이 대부분이실 겁니다. 네. 문제가 하나 생겼고 함께 의논해보아야 할 것 같습니다.

PAPACHA님이 말씀하시길 1.0.6의 티켓중의 하나인 'UTF8 미지원 database에 대한 field length 전처리 지원 문제' 링크 가 1.0.5 버전의 티켓 링크 을 포함한 여러 티켓들에 하위 종속적입니다. 이곳 QA 게시판이나 버그 게시판에도 종종 보고되는 'null' 경고창 표시 문제나, 일부 트랙백을 받아들일 때 블로그 화면이 깨져나오는 오류등도 전부 저 티켓에 종속적인 문제입니다.

이 문제에 관해서 이해를 돕기 위해 설명을 드리자면, 유니코드가 정식으로 지원되지 않는 MySQL 4.1 이전의 MySQL에서는 UTF-8의 한 글자가 무조건 3바이트를 차지하게 됩니다. (유니코드를 정식으로 지원하는 버전에서는 언어마다 차지하는 용량이 다릅니다. 영문자의 경우 1바이트, 한글이나 일어, 중국어등의 경우 3바이트입니다.) 현재 태터툴즈는 MySQL 4.1 이전의 버전일 경우 3바이트로 통일하여 강제로 집어넣습니다. 그런데 이 경우 가끔 DB의 필드 크기를 넘는 값을 넘겨주는 때가 생깁니다.

길이에 잘라서 넣으면 되지 하시는 분들, 맞습니다. 지금도 잘라서 넣고 있습니다. smile 그런데 이게 3바이트 단위다보니 어쩌다가 문자의 중간이 잘리는 경우가 발생합니다. 이럴 경우 해석 불가능한 문자가 마지막에 같이 저장되게 됩니다. 그게 출력될 때 위에서 언급한 오류들이 발생합니다.

그래서 아예 MySQL 3 버전의 DB를 사용하는 유저를 위해 문자열의 종류를 판단하여 정확하게 잘라내는 함수를 만들어, 해당 버전일 경우 '잘 잘라주도록' 만드는 것이 최선입니다. 이를 위한 함수들이 오늘자 trunk와 sandbox에 추가되어 있습니다. 문제는 이 함수들을 이제 char나 varchar와 같은 길이가 지정되어 있는 데이터베이스의 insert 루틴이나 modify루틴에 모두 적용시켜야 한다는 점입니다. 태터툴즈 소스 전반에 걸쳐 광범위하게 존재하죠. sad

소스 수정과 추가는 모두 같이 붙잡으면 하루나 이틀이면 하겠지만, 언제나 벌레잡기가 더 오래걸리겠죠? 또한 기존 MySQL 3 사용자들의 DB를 검사하여 올바르게 수정해주는 루틴도 추가되어야 합니다.

이후 DB의 종류에 따른 에러 발생은 없어지겠지만, 아마도 MySQL 3사용자들은 위에서 설명드렸듯 '무조건 3바이트' 때문에 MySQL 4.1 이상의 사용자 분들보다 제목이나 트랙백, 덧글 등에서 약간은 적은 양의 데이터들을 저장할 수 있게 될 것입니다. (현재도 잘라넣기 때문에 사실 지금하고 똑같습니다. big_smile )

...드디어 결론에 왔습니다.

* 1.0.5 릴리즈의 티켓에 해당되는 리더부분만 우선 수정한 후 이 티켓을 1.0.6으로 가지고 가고 일정대로 1.0.5를 내놓느냐
    - 이 경우 일정을 준수하게 됩니다.
    - 1.0.6까지의 시간이 1달이 생기기 때문에 MySQL 4.1 미만의 사용자들을 위한 term이 너무 늦다는 의견이 있었습니다.
* 1.0.5 를 우선 내놓고 1.0.6 발표 이전에 MySQL 3 사용자들을 위한 1.0.5.1을 내놓느냐
    - 일정을 맞출 수 있습니다.
    - 이 경우엔 MySQL3 사용자들이 번거롭습니다.
* 1주일 릴리즈 일정을 연기하고 중간에 베타버전을 한 번 더 내놓느냐
    - 환경에 상관없이 에러가 없는 버전을 모든 사용자가 동시에 사용할 수 있습니다.
    - 이 경우 일정을 준수하지 못하니 이후에 계획되어 있던 모든 릴리즈 일정이 한 주씩 늦춰지게 될 겁니다.

의 선택의 문제였고, 우선 PAPACHA님과 저는 사용자들의 버그로부터의 불편함이나 여러 버전에 따른 혼동을 막기 위하여 마지막 방법이 가장 낫다는 결론에 도달했습니다.

1주 연기 후 중간에 베타버전을 한 번 더 두는 식으로 beta 3를 5월 4일 (목요일) 오후 3시에, 1.0.5 final을 5월 9일 (화요일) 오후 3시에 발표하는 쪽으로 일정을 수정할까 합니다. 어떻게 생각하시나요?

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

inureyes의 웹사이트

2 chester이 작성한 답글

  • 가입일자 2006-04-03
  • 글: 557

답글: 1.0.5 의 발표 일정에 관하여

파파차님도 이 문제는 한번은 반드시 넘어야 할 산...어차피 넘어야 할것 지금 넘어버리자고 그러시네요.
수많은 사용자분들이 아쉬우시겠지만, '바로서는 기본(?)'을 위하여, inureyes 님의 제안에 동의합니다.. smile

3 Peris이 작성한 답글

  • Peris
  • 분재가
  • 오프라인
  • 가입일자 2006-04-12
  • 글: 531

답글: 1.0.5 의 발표 일정에 관하여

일주일간의 시간이 추가된다면 이 기회에 DB모듈화를 같이 진행하는 것도 괜찮지 않을까요?
시간상으로는 충분할거 같습니다만 smile

Peris의 웹사이트

4 chester이 작성한 답글

  • 가입일자 2006-04-03
  • 글: 557

답글: 1.0.5 의 발표 일정에 관하여

Peris 작성:

일주일간의 시간이 추가된다면 이 기회에 DB모듈화를 같이 진행하는 것도 괜찮지 않을까요?
시간상으로는 충분할거 같습니다만 smile

저 무식해서 죄송한데..  DB모듈화가 무엇입니까 ?? 흑 ~

5 daybreaker이 작성한 답글

  • 지역 대한민국, 대전, KAIST
  • 가입일자 2006-04-04
  • 글: 1,319

답글: 1.0.5 의 발표 일정에 관하여

chester 작성:

저 무식해서 죄송한데..  DB모듈화가 무엇입니까 ?? 흑 ~

현재는 MySQL query 문들이 코드 중간중간에 직접 들어가 있지요. mysql 입출력 함수만을 따로 모아서 클래스로 만든 다음, 현재의 query 문들을 모두 이걸로 대체하는 겁니다.

예를 들면
class MySQL extends DB {
...
}

$mysqlDB = new MySQL();
$mysqlDB->connect("server", "id", "password");
$mysqlDB->select_db("dbname");
$mysqlDB->select_table("tablename");
$mysqlDB->count_rows("condition");
$mysqlDB->find_all("condition", "orderby", offset, limit);
$mysqlDB->insert("valuearray");
...
과 같은 겁니다. 잘 응용하면 mysql을 쓰지 않는 file db 형태로 할 수도 있습니다. (MetaBBS가 이런 방식입니다. dbname.php마다 MySQLAdapter와 같은 클래스가 있고, 이 클래스를 이용하는 model_* 이름의 함수들이 있어서 통일된 인터페이스를 제공하고 있지요.)

그러면 mysql 관련한 문제가 발생했을 때 그 클래스 하나만 수정하면 되니까 전체 코드를 다 건드려야 하는 일이 없어지고, 또한 mysql 뿐만이 아니라 postgresql, sqlite 등 다른 종류의 DBMS를 사용할 수 있도록 컨버팅하는 것도 매우 쉬워집니다.

하지만 거기까지 이르기 위해서는 정말 엄청나게 많이 뜯어고쳐야 할 겁니다. (특히 다중 backend를 지원한다면 설치 UI 쪽도 변경이 될 필요가 있지요)

daybreaker (2006-05-01 16:21:27)에 의해 마지막으로 수정

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

daybreaker의 웹사이트

6 inureyes이 작성한 답글

  • 지역 대한민국 > 포항
  • 가입일자 2006-04-03
  • 글: 4,471

답글: 1.0.5 의 발표 일정에 관하여

모듈화는 장기적 로드맵대로 1.1로 넘깁시다 ~

1주일이라고 해도 제작 3일 테스트 4일이니 실제로는 3일 번거죠;; ㅠ_ㅠ

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

inureyes의 웹사이트

7 PAPACHA이 작성한 답글

  • PAPACHA
  • 정원의 마술사
  • 오프라인
  • 가입일자 2006-04-13
  • 글: 127

답글: 1.0.5 의 발표 일정에 관하여

daybreaker 작성:
chester 작성:

저 무식해서 죄송한데..  DB모듈화가 무엇입니까 ?? 흑 ~

현재는 MySQL query 문들이 코드 중간중간에 직접 들어가 있지요. mysql 입출력 함수만을 따로 모아서 클래스로 만든 다음, 현재의 query 문들을 모두 이걸로 대체하는 겁니다.

그러면 mysql 관련한 문제가 발생했을 때 그 클래스 하나만 수정하면 되니까 전체 코드를 다 건드려야 하는 일이 없어지고, 또한 mysql 뿐만이 아니라 postgresql, sqlite 등 다른 종류의 DBMS를 사용할 수 있도록 컨버팅하는 것도 매우 쉬워집니다.

하지만 거기까지 이르기 위해서는 정말 엄청나게 많이 뜯어고쳐야 할 겁니다. (특히 다중 backend를 지원한다면 설치 UI 쪽도 변경이 될 필요가 있지요)

mysql 입출력 함수만 따로 모으는 것은 큰 의미가 없습니다. model마다 특성과 check routine등이 상이하기 때문입니다. mysql 관련뿐만이 아니라 model로서 object화시키는 것이겠지요. 이에 대한 구현이 Tattertools.Data.* components입니다. 데이터 export/import 기능이 이 components를 사용합니다. 그러나 이 components가 구현되기 전에 지금의 lib/model/*이 구현되어 사용되었기에 추가되는 기능이 아닌 경우는 계속 lib/model/*을 사용하고 있습니다. 앞으로 점차적으로 이들 사용이 Tattertools.Data.* components의 사용으로 변경될 것입니다.
또한 단순히 mysql 입출력의 문제에 대해서는 Eolin.PHP.Core component에 포함된 DBQuery와 TableQuery classes를 확장해서 구현할 수도 있겠습니다.

8 daybreaker이 작성한 답글

  • 지역 대한민국, 대전, KAIST
  • 가입일자 2006-04-04
  • 글: 1,319

답글: 1.0.5 의 발표 일정에 관하여

글을 수정하는 사이에 답글들이 또 달렸군요;)
태터툴즈도 Data Component들이 model을 구현하고 있기 때문에 그쪽으로 맞춰서 개발하는 것이 좋겠지요.
model이 여러 종류가 존재하는 현재의 태터툴즈 형태더라도, db query 부분을 각 모델별로 따로 모아둔다면 여러모로 편리할 거라 생각합닙다.
(각 model 별로 db query 넣는 부분들이 있는데, 이러한 model들 자체를 dbms 별로 각기 구현할 수 있을 정도로―실제 그렇게 하진 않더라도―해둔다면 db 관련 문제에 보다 쉽게 대처할 수 있지 않을까요?)

daybreaker (2006-05-01 16:28:15)에 의해 마지막으로 수정

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

daybreaker의 웹사이트

9 PAPACHA이 작성한 답글

  • PAPACHA
  • 정원의 마술사
  • 오프라인
  • 가입일자 2006-04-13
  • 글: 127

답글: 1.0.5 의 발표 일정에 관하여

우선 티켓 #67 자체에 한하여 진행되었으면 합니다. 모률화나 객체화로 확장하게 되면 버그 레벨이 너무 높아집니다.

10 iarchitect이 작성한 답글

  • 지역 서울
  • 가입일자 2006-04-21
  • 글: 20

답글: 1.0.5 의 발표 일정에 관하여

디비 모듈화 이야기가 나와서 그런데 Oracle XE 버전이 나왔습니다. 개인적으로 웹서버를 구성할 수 있는 사람에겐
땡기는 부분인데 고려해 주셨으면 합니다.

압니다. 떼쓰고 있는거 ...^^'

인간이 노력하는 모든 분야에서 80%의 결과는 20%의 활동으로 생겨난 것이다.

iarchitect의 웹사이트

11 daybreaker이 작성한 답글

  • 지역 대한민국, 대전, KAIST
  • 가입일자 2006-04-04
  • 글: 1,319

답글: 1.0.5 의 발표 일정에 관하여

PAPACHA 작성:

우선 티켓 #67 자체에 한하여 진행되었으면 합니다. 모률화나 객체화로 확장하게 되면 버그 레벨이 너무 높아집니다.

네. 당장 하기는 무립니다. -_-;

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

daybreaker의 웹사이트

12 Peris이 작성한 답글

  • Peris
  • 분재가
  • 오프라인
  • 가입일자 2006-04-12
  • 글: 531

답글: 1.0.5 의 발표 일정에 관하여

헛.. 살짝해본 말에 이런 반응이..;;
로드맵을 제대로 이해 못한 저의 불찰이군요.
1.1에서 할 예정이었었군요.
1.0.6에서 할거라 생각하고 있어서 기왕 건드는 김에 미리해두는게 편하지 않을까라고 생각했네요. smile

Peris의 웹사이트

13 PAPACHA이 작성한 답글

  • PAPACHA
  • 정원의 마술사
  • 오프라인
  • 가입일자 2006-04-13
  • 글: 127

답글: 1.0.5 의 발표 일정에 관하여

베타 3가 오늘 밤 늦게 나올 것 같습니다.
utf-8에 대한 완벽한(?) 처리가 매우 복잡합니다.