http://www.toosweettobesour.com/2008/07 … -closures/

PHP 5.3에서 드디어 anonymous function (일명 lambda)가 구현된다(되었다?)는 소식입니다... (....)

혹시 Stored Procedure를 사용하실 생각이시면 MySQL 5.1(정확히 버전 몇인지는 기억이 안나네요) 이상으로 넘어가셔야 합니다. 이 이전에서 Stored Procedure를 사용할 경우 DBMS 자체의 query cache를 사용하지 않아서 성능이 심각하게 저하된다고 하더군요

그냥 단순하게 CRUD 부분을 모델 형태로 추상화하는 것은 어렵지 않겠으나, 말씀하신 대로 SQL의 고급 기능들(stored procedure, view 등)을 사용하게 될 경우 이를 어떻게 추상화할 수 있을지(ORM과 같은 형태가 되겠지만 ORM이 꼭 정답이라고 생각하고 접근할 필요는 없겠지요) 고민 중입니다.

제가 써본 ORM 프레임웍이 Django밖에 없기 때문에, 보다 다양한 프레임웍에서 고급 SQL들을 어떤 식으로 지원하고 있는지 알아볼 필요가 있습니다. Django의 경우 foreign key가 걸렸을 때 자동 삭제 등을 위해 TRIGGER 정도까지만 사용하는 것 같더군요. Custom SQL을 가급적 사용하지 않는 쪽으로 해야겠으나 실제 텍스트큐브에서 사용되는 쿼리의 복잡도가 어떻게 되는지 한 번 조사해봐야겠습니다.

그리고, php 5.2로 올라가면 xml dom 처리 루틴을 php 자체 라이브러리에서 가져다 쓸 수 있게 되므로, 현재 구현되어 있는 컴포넌트는 불필요해지지 않나 싶습니다. 역시 관련하여 TTXML 백업·복원 및 환경설정, 스킨·플러그인 정보 읽어들이는 부분을 다 새로 짜야겠네요...;;

저도 4번 고고싱

(ㅋㅋㅋㅋ)

문제는, DB 프레임웍이 어느 수준까지 추상화를 지원하느냐겠지요. 그에 따라 구현의 난이도나 에뮬레이션의 필요성 등이 많이 달라질 겁니다. SQL을 하나하나 전부 다 추상화하는 것이 DBMS 독립성을 지키기에는 더 낫겠지만 구현의 난이도는 올라가고, 사용자정의 SQL을 허용한다면 VIEW와 같은 것을 그냥 써버리면 되게 되는 대신 DBMS 의존성이 생길 수가 있지요.

다른 DB 프레임웍들은 VIEW 같은 거 어떻게 처리하나 찾아봐야겠군요.; Django의 경우 VIEW를 따로 쓰는 것 같지 않던데...

넘어오기 그런 분들이 계신다면 2.0과 1.7 트리의 지원을 병행하는 쪽으로 하는 것도 고려해 볼 수 있겠습니다. 이제 결정을 할 시간입니다. 어차피 MySQL 4.1 이상에서 지원하는 view 등을 사용하기 위해서는 다른 DBMS에 대한 고려도 해야 하므로, 타협 많...이 해서 MySQL 4.1 / PHP 5.2도 괜찮다 싶긴 합니다.

이 프레임워크를 2년 이상 쓴다는 가정이 있으면 그냥 4번으로 가도 되겠습니다. 두 분 이상이 찬성하시면 MySQL 5 / PHP 5.2로 가고, 또 다른 의견이나 이건 안되겠다 싶은 분들께서는 의견 주시면 계속 토의해 보도록 하죠.^^

2.0에서는 좀 강하게 밀어붙이는 게 어떨까 싶습니다. 저는 4번(못해도 3번)에 한 표 던집니다.

DB 백엔드 설계 문서가 대충 정리되는 대로 실제 코딩 작업에 들어가야 할 것 같은데, 새로운 branch를 만들어서 해야 하지 않을까 싶습니다.

ps. 설계 문서가 좀더 다듬어지면 곧 TNF 메일링으로 돌리겠습니다. Peris님이 말씀하신 '태터 프레임워크' 정도 수준에 가까워지리라 생각되는군요.; 좀 많이 갈아엎을 생각입니다;

gofeel 작성:

흠 현재 사용하고 있는 php버전을 빠르게 수집할 방법 없을까요...........흠-_-

http://koreahosting.or.kr/tt/board/ttbo … tro_member
http://koreahosting.or.kr/tt/board/ttbo … ro_member1

물론 해당 한국인터넷협회 회원사는 일부겠습니다만... 한번 살펴볼까요?;

어차피 알아보아도 결정에 큰 영향은 미치지 않을듯 싶습니다...

릴리즈 일정을 잡되, gofeel님 말씀처럼 충격 흡수가 요구되니 2.0과 1.7 가운데의 브릿지가 필요하겠군요. 편법이기는 하지만 2.0 개발 일정 중에 1.8을 내놓고, 1.8의 다른 부분은 1.7과 동일하지만 DB 백엔드와 요구사항만 올리는 식의 접근도 버퍼식으로 필요할 것 같기는 합니다.

어떤 쪽이든, 차후 메이저 버전에 대한 요구사항은 결정지어야 할 것 같네요. 그럼 정리해서 다음의 안들이 있습니다.

1. MySQL 4.1 / PHP 4.3
2. MySQL 4.1 / PHP 5.1
3. MySQL 5 / PHP 5.1
4. MySQL 5 / PHP 5.2

이제 골라보죠. 저는... 4번?

흠 현재 사용하고 있는 php버전을 빠르게 수집할 방법 없을까요...........흠-_-

http://koreahosting.or.kr/tt/board/ttbo … tro_member
http://koreahosting.or.kr/tt/board/ttbo … ro_member1

물론 해당 한국인터넷협회 회원사는 일부겠습니다만... 한번 살펴볼까요?;

gofeel 작성:

Creorix 작성:

만약 텍스트큐브 2.0이 지원 사항을 PHP 5로 높인다면 지금 MySQL UTF-8 서버와 EUC-KR 서버로 나누어서 상품을 제공하는 것처럼 PHP 4와 5로 서버 나누어서 호스팅 제공할지도 모르겠습니다 ㅡㅡ;;

보통 그게 제로보드 4때문에 생긴 제약이라

euc_kr/php4/mysql3.x
utf-8/php5/mysql4~5

로 나누더군요.

뭐 그렇다면 PHP 5로 올라가도 되지 않을까요? 어차피 텍스트큐브 쓰시는 분들은 UTF-8 DB를 선택하실테니 말입니다

네, 문제는 지금 일정대로 2.0을 발표한다면 충격흡수가 어려울 것이라는 생각이 듭니다.

php5 & mysql 4로 확정한다면, 릴리즈 일정을 길게 갈 필요성이 있어 보입니다.

+ 이러한 충격을 흡수할 보조 프로그램들이 필요하다고 생각합니다.  현재의 ttxml 백업은 플랫폼 간 교환과 일반적인 백업상황에는 적합하지만, 모든 환경이 유지되는 업그레이드용 백업에는 딱 맞다고 보기는 힘들죠.