Login | Register
My pages Projects Community openCollabNet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Catacomb] DBMS abstraction



On Friday, September 6, 2002, at 09:40 AM, Sung Kim wrote:
We need dbms.[ch] which is high level of DB interface which can deal all kind of DBMS. Behind that, we can have dbms_mysql.[ch], dbms_oracle.[ch] and so on. So your work is really great.

Agreed.

In that sense, do we really need dbms_mysql.h? The data is in dbms_mysql.c and the interface should be same as dbms_mysql.h and dbms_oracle.h. So I think the low level interface must be defined in dbms.h so that the other dbms_xxxx.c developer can implement the function.

Also agreed, we should unify dbms.h and dbms_mysql.h...For that matter, dbms.c and dbms_mysql.c could be unified as well. Best would be to have a dbms.h that is not database specific (using statics in the .c file and having ids in the structs is one way to hide implementation specifics...) We can play that out over the next couple of weeks...

Also we might need to consider *hooker* to support multiple DB.

Yup, that's my hope.

Also would you like to make a new branch?

The changes that this incorporates are important enough for the safety of the server that I'd say it should go on the main trunk. Let me think about it some more. (Usually I reserve branches for either specific releases or major features, not security or bug fixes.)

* The dbms struct carries it's own memory pool, should that be a child
of another pool? Given that each query will be generating a fair number
of string allocations, should each query have it's own child pool? I'm
unclear as to when memory pools are cleaned up, so guidance (or URL's)
would be appreciated.

I think we should pass pool when we create DB. Since we open DB only when apache start, and close when apache stop, the pool can be larger.

* coding style/variable naming comments are always appreciated, I can
work with whatever style you like. (I often set my tab stops at 4, but
I'll try to make sure it looks ok with 8.)

To avoid name conflict, please use prefix, "dav_repos_".

For structs? I notice that most functions in dbms.c are prefixed with "dbms_", it might be good to enforce a naming convention on all (non-static) functions as well (since that's where you'll end up with linking nightmares).

I plan on being at the interop event Tuesday afternoon and Wednesday,
hope to see you there!

Did you aware that there is mod_dav_psql. I think we might look at that one tool.

Agreed.

I'll be at the event only Monday and Tuesday morning. :-)

I appreciate your work again.