노르웨이 여행 다녀온 사이 논의가 계속 있었군요.;

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

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

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

daybreaker (2008-06-16 22:17:55)에 의해 마지막으로 수정

어차피 sqlite를 지원하려고 한다면 일부 고급 SQL에 대한 에뮬레이션 구현이 필요해지긴 합니다. 허나 구태여 mysql 3.x 및 4.0 이하 버전용을 제작하기 위해 노력을 쏟을 필요는 없겠지요.

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

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

현재 쓰고 있는 초저가 호스팅이 mysql 5 & php 5.2군요

저도 4번 고고싱

(ㅋㅋㅋㅋ)

네 그럼 그렇게 공지를 하겠습니다-

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

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

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