Pictures 음... 2017/05/11 00:05 by WSID


뭔가 글을 쓰려고 낙서를 잠깐 그리긴 했는데, 글은 안써지고, 낙서는 아깝고 해서.. 그냥 낙서로 올려봅니다. (...)

복잡한 기능보단 단순하게~!

미분류 2017년 04월 25일의 Onggi 2017/04/26 00:55 by WSID



안녕하십니까.. 많이 늦었군요. WSID입니다.
이번의 Onggi입니다.
field-compound 브랜치에서 작업중입니다.

1. OnggiCompoundData, OnggiFieldContentData

OnggiCompound의 하위 클래스 중에서 먼저 OnggiCompoundData를 작성하였습니다.
OnggiCompoundData는 전체가 값으로서 취급되는 값 타입을 지정할 수 있습니다. 예를 들면, 성, 중간, 이름으로 구성된 전체 이름이나, 2개 또는 3개의 값으로 이루어진 벡터값을 들 수 있습니다.

typedef struct {
    char *first;
    char *middle;
    char *last;
} Name;
typedef struct {
    float x;
    float y;
} Vector2;

OnggiFieldContentData는 OnggiCompoundData를 필드로서 추가하기 위해 작성하였습니다. OnggiFieldContentData를 사용한 경우, OnggiCompoundData에 포함된 필드들을 모두 해당 필드의 하위 필드로 추가합니다.


2. OnggiFieldHierarchy

위에서 언급된 OnggiCompoundData와 같이 필드의 값이 하위 필드의 묶음으로 구성될 수 있습니다. 게다가 동일한 구조가 반복될 수도 있습니다. 따라서 구체적인 하위 필드를 가리키기 위해 작성하였습니다.


3. OnggiFieldInstance

또한 객체나 구조체에서 값을 읽고 쓸 수 있는 OnggiFieldInstance와 하위클래스들을 작성하였습니다.


4. 이외에도

이외에도 필드의 타입을 결정하는 다양한 OnggiFieldContent의 하위 클래스들 (OnggiFieldContentBoolean 등...)이 작성되었습니다.
또한 OnggiFieldContent가 능동적으로 OnggiField의 "g-type"을 결정하도록 수정하였습니다.


5. 앞으로

OnggiCompoundTable에 대한 INSERT, UPDATE, DELETE, SELECT를 수행할 수 있는 기능을 구현할 예정입니다. 하지만 자체적인 기능 구현 보다는 libgda을 최대한 활용한다는 느낌으로 구현하고자 합니다.
  • 프로그램적으로 문장을 구성하는 방법을 위해 내부적으로 GdaSqlBuilder를 사용합니다.
    프로그램은 함수 호출을 통해 명령문을 조립합니다.

  • 문자열에서 읽어들인 명령문을 변환하여, GdaSqlParser에 넘깁니다.
    명령문을 읽어들여서 GdaStatement나 GdaBatch를 구성합니다.
또한 OnggiCompoundObj와 OnggiFieldContentObj를 추가할 계획입니다.

이외에도 GValue를 취급하는 방법을 변경할 계획입니다.


6. +

흐으... 글을 오랫만에 써서 그런지 머리가 아프군요... (...)
지난주도 약간 정신없이 보내기도 했었고 하니..

이번 2주 (또는 3주)는 아직 해야 할 것도 있고, 멘탈도 조금 정리할 겸 해서  조금 느긋하게 진행 할 듯 합니다. (...)

미분류 2017년 4월 2일의 Onggi 2017/04/02 01:26 by WSID

안녕하십니까? 이번에도 Onggi를 작성중에 있습니다.

이번에는 딱히 새로운 기능이 추가되진 않았습니다. 

현재는 OnggiTable과 OnggiColumn의 기능을 대체할 수 있는 OnggiCompound와 OnggiField를 작성하고 있습니다.

현재 작성된 부분은 다음과 같습니다.
  • OnggiCompound
  • OnggiCompoundTable
  • OnggiInstanceCreator
  • OnggiField
  • OnggiFieldInstance
  • OnggiFieldContent
  • OnggiFieldContentLeaf
  • 단순한 값에 대한 OnggiFieldContentLeaf의 하위 클래스들

작성중인 부분은 다음과 같습니다.
  • OnggiCompoundData
  • OnggiFieldContentData
  • OnggiFieldHierarchy
앞으로 작성할 부분은 다음과 같습니다.
  • OnggiCompoundObject
  • OnggiFieldInstance의 하위 클래스들

일단은 해당 클래스들을 작성하고 나면, 기존의 OnggiTable 등을 대체하고자 합니다.

이후에는 바로 1:다, 다:다 관계에 대한 구현을 진행할 계획입니다.



OnggiInstanceCreator

OnggiCompoundData를 구성하면서 생각을 해야 했던 것이 어떻게 구조체를 구성할 것인가였습니다. Java나 C#을 비롯한 많은 언어에서는 타입 정보에서 객체를 만드는 통일된 방법을 제공합니다. 그러나 C를 쓸때는 GObject도 자주 쓰지만, 단순 구조체도 많이 사용합니다.

문제는 단순 구조체의 경우, 만드는 통일된 방법이 없습니다. 단순한 경우는 malloc으로 해결되지만, 일반적으론 함수를 통해 생성합니다.  그리고 함수의 파라미터가 각기 제각각입니다. (...)

이러한 제각각인 생성 방법을 필요에 맞게 구성하기 위해서 InstanceCreator를 만들었습니다. Compound와 값들을 받아서 구조체나 객체를 생성해 주도록 합니다.

Computing 2017년 03월 14일의 Onggi 2017/03/14 02:07 by WSID


안녕하십니까. 이번에도 어김없이 WSID입니다. 'u' ;;;

구상을 하다 보니 머릿속이 많이 복잡해서, 진척이 그리 많지 않았습니다.


1. OnggiMOContainer

OnggiModuleObject 들은 포함 관계를 통해 계층 구조를 이루고 있습니다.
  • OnggiModule은 OnggiTable을 포함하고 있으며,
  • OnggiTable은 OnggiColumn을 포함하고 있습니다.
OnggiModule, OnggiTable은 OnggiMOContainer입니다. OnggiMOContainer는 다른 OnggiModuleObject를 포함하여 계층 구조를 형성하며, 추가로 OnggiConstruction과 잘 묶일 수 있는 연관된 기능을 제공합니다.
  • 이름이나 경로로 계층 구조에서 OnggiModuleObject를 얻습니다.
    이 기능은 OnggiConstruction에서 이미 있는 객체를 찾을 수 있도록 합니다.

  • 같은 이름의 객체가 추가되는 것을 막습니다.

  • OnggiMOContainer에 OnggiModuleObject를 추가하는 구체적인 함수를 제공합니다.
    OnggiMOContainer에서 OnggiConstruction에 함수를 등록해 놓았으므로, OnggiModule이나 OnggiTable에서 OnggiConstruction에 함수를 등록해 두지 않아도 됩니다.

하지만, 하나의 OnggiMOContainer에 다른 종류의 OnggiModuleObject들이 추가될 가능성이 있습니다. 예를 들면 OnggiTable이 OnggiColumn, OnggiFKey를 포함할 수 있다는 점입니다. 따라서 각각의 종류별로 관리가 필요하다는 생각이 들어, OnggiMOContainer에서 객체의 추가를 구현하지 않고, 각각의 하위클래스들 (OnggiModule이나 OnggiTable)에서 객체의 추가를 구현하고자 하였습니다.

하지만 이렇게 되면, 위에서 언급된 기능들을 각각 따로 구현해 주어야 한다는 번거로움이 생깁니다. 더구나, 이러한 번거로움은 새로이 추가되는 클래스에서도 나타나므로 이러한 방식을 적용하지 않도록 할 생각입니다.

일단은 그냥 데이터의 중복을 감수하고, 종류별로 따로 리스트나 셋에 추가하도록 할 계획입니다.
그리고 잠수함 패치 (...)로 일부 종류에 따라 이름 없는 OnggiModuleObject를 추가할 수 있도록 했습니다.

(이런 고민을 했다는 것이 큰 그림에 문제가 있을지도 모른다는 신호일지도 모르겠군요... 다시 말하면, 큰 그림에 문제로 인해 여러 문제가 나왔고, 고심을 했지만 결국은 미봉책일지도 모른다는 점이겠군요.)


2. OnggiCompound와 OnggiField

객체 타입을 저장하는 기능은 어느정도 갖추고 있습니다. 예를 들면 사람에 대한 객체를 저장할 때 이름, 성별, 생년월일을 저장할 수 있습니다.

그러나 복합적인 "값 타입"을 저장하는 면에서 OnggiColumn은 한계를 보였습니다. 예를 들면 2차원 좌표는 X, Y 좌표로 구성되어 있어서, 2개의 컬럼에 따라 배치가 되어야 하지만, OnggiColumn은 1개의 컬럼에 묶여 있기 때문에 문자열로 변환하여 저장을 하거나 커스텀 접근 함수를 사용해야 하는 불편함이 따릅니다. 따라서 이러한 복합적인 부분을 포용할 수 있는 OnggiField를 구상하고자 하였습니다. 하지만 이런 구상에는 또 많은 시간이 걸렸습니다.

처음에는 단순히 OnggiField 하나만으로 쉽게 구성이 될줄 알았습니다. 처음엔 하나의 기능만 고려가 되었었습니다.
  • (1) 복합적인 타입의 값과 단순한 타입의 값들을 서로 변환
    2차원 좌표는 바로 저장이 안되기 때문에, REAL 형의 값 2개로 분화합니다.
그러나 구조체와 객체의 구조를 나타내는 OnggiCompoundData와 OnggiCompoundObj를 고려하다보니 OnggiField에 추가로 필요한 기능이 생겼습니다.
  • (2) 구조체나 객체에서 값을 읽거나 쓰는 방법 제공.

  • (3) OnggiField가 단순히 여러 컬럼이 아니라, 다른 OnggiField들로 분화되면서 계층을 이룹니다.
따라서 이러한 기능들을 지원해 줄 수 있어야 합니다. 그러나 각각의 기능들이 서로 다른 만큼 하나의 클래스로는 표현하지 못하고, 3개의 타입으로 분화 되었습니다.

일단은, 저는 (2)를 OnggiField의 하위 클래스를 통해서 제공할 구상을 했습니다. (2)의 항목은 OnggiCompoundData와 OnggiCompoundObj에서만 사용되는 기능이며, 해당 기능에서 값을 읽거나 쓰는 방법이 교체되는 일이 일어나지 않기 때문입니다.

(3)의 경우는 OnggiFieldHierarchy라는 간이 구조체를 통해 제공하고자 합니다. (2)와는 달리 (3)의 경우는 다른 종류의 OnggiCompound에도 영향을 미치고, 하나의 OnggiField가 여러 계층 구조에 나타나는 경우도 생깁니다. 즉, 동일한 계층 구조가 여러 군데에서 나타날 수 있습니다. 따라서 쉽게 복사가 될 수 있는 간이 구조체를 사용하기로 하였습니다.

(1)의 기능은 OnggiFieldContent라는 인터페이스를 통해 제공하기로 하였습니다. OnggiField의 하위 클래스로 구성하는 것도 나쁘진 않습니다만, 인터페이스를 구성하면OnggiCompound의 하위 클래스도 구현이 가능하여, 불필요한 클래스를 줄일 수 있습니다.



3. OnggiTable과 OnggiColumn

OnggiTable과 OnggiColumn은 OnggiCompoundTable과 OnggiField로 대체할 예정입니다. 만일 특정한 테이블이 필요하다면 OnggiCompoundTable을 제공할 수 있고, 특정 컬럼이 필요하다면 OnggiFieldHierarchy를 제공할 수 있을 것입니다. (OnggiField의 경우는 계층 정보가 없기 때문에...)

이러한 결정을 내린 이유는 OnggiTable과 OnggiColumn에 맞추어 이에 맞는 반대편 클래스가 필요했었기 때문입니다. 만일 OnggiIndex라는 클래스가 추가된다면, OnggiCompoundTable를 위해 다른 클래스가 추가되어, OnggiIndex로 분화하는 기능을 갖추어야 합니다. 이러한 중복을 줄이기 위해 OnggiTable과 OnggiColumn은 제거될 예정입니다.



흠... 쓰다보니까 제가 봐도 많이 복잡하군요... (...)
원래는 추가된 점이나 바뀐점을 적어야 하는데, 이번에는 구상한 점들을 적어놨군요..;;

Computing 2017년 02월 26일의 Onggi 2017/02/26 12:16 by WSID

안녕하십니까. 이번에도 Onggi를 수정하였습니다.



특별한 기능 추가는 없었지만, 이번에도 내부 구조 변경 등이 있었습니다.

1. ModuleFactory, ModuleFactoryGroup에서 ModulePool로 변경

Module이 Store별로 상태를 가지고 있어야 할 경우를 대비하여, 아예 각 Store별로 Module 객체를 생성하도록 하였습니다. 그러나 Module이 Store별로 따로 가지고 있어야 할 상태가 없어서, Store 하나 마다 Module을 생성하는 것은 낭비가 되었습니다.

따라서 Store마다 Module을 생성해줄 ModuleFactory 또한 불필요해 졌습니다. 대신 Module을 직접 등록할 수 있는 ModulePool을 구성하였습니다.



ModuleFactory을 생성한 다음 ModuleFactoryGroup에 추가

Module을 생성한 후, ModulePool에 추가


ModuleFactoryGroup에서 ModuleFactory를 찾은 후 ModuleFactory에서 Module 생성

ModulePool에서 Module을 찾는다.



2. 앞으로

OnggiField, OnggiCompound

현재 OnggiColumnInstance와 OnggiTableObj을 통해 객체를 저장하고 있습니다. 그러나 OnggiColumnInstance에 기반한 방법은 독특한 타입을 저장할 때 사용할 수 있지만, 구조체와 같이 한 컬럼에 넣기 어려운 복잡한 타입을 다룰 때에는 한계를 곧잘 드러냅니다.

따라서, 지난 글에서 이야기 한 것과 같이, OnggiColumn을 단순화 하고, OnggiColumnInstance에서 추가된 역할을 새로이 OnggiField로 옮겨 보려고 합니다.
또한 OnggiTable이 OnggiField를 받을 수 있으면 좋겠지만, 일단은 어려울 것 같으므로, OnggiCompound도 추가하고자 합니다.

주로 1:n, n:n을 처리하기 위해 OnggiRelation도 추가할 생각을 하고 있지만, 일단 이것부터 처리하는 것이 우선이 될 듯 합니다.


이상입니다. 'u'

1 2 3 4 5 6 7 8 9 10 다음