Login | Register
My pages Projects Community openCollabNet

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

RE: [Catacomb] [Ann] Catacomb ODBC

Hi all,

> > ODBC, apart from being a viable solution technically speaking, could 
> > have been, IMHO, a way to gather more users, which in turns means more 
> > developers, which in turns mean a healthy community and so on...
> The idea was to make it so that we can accommodate multiple 
> repository interface modules with the same architecture, 
> which implies accommodating a larger user base than can be 
> supplied by any one access method.

I absolutely concur it's a good thing for the architecture to allow
multiple, pluggable access methods, yes!

However, I tend to think ODBC makes per-RDBMS modules redundant. My question
is: why should we incur the additional effort of writing RDBMS-specific
ports when ODBC gives us an efficient, one-size-fits-all solution?

I also don't understand how ODBC could be at odds with stored procedures.
SP's are fully supported by ODBC. What can be achieved via native interfaces
that cannot be achieved via ODBC?

Please take into account I formulate these questions in all intellectual
honesty. Rather than "deffending" a point of view, I'm sincerely interested
in understanding what is it that I fail to see...

> > Anyway, I'll take your reply as a "No, thanks" to the inclusion of the 
> > current ODBC code, which most probably will end up on Sourceforge 
> > then. Should you want to integrate (parts of) it in the future, don't 
> > hesitate.
> I think the reply is more one of, "thank you *very* much for 
> the code contribution" and we'd like to integrate this code 
> into Catacomb, but using an architecture that accommodates 
> both standard (ODBC) and database-specific (MySQL, Oracle, 
> DB, etc.) access methods. I'm also open to suggestions of how 
> to integrate the ODBC code into Catacomb right now, perhaps 
> by using appropriate #ifdefs?

This addresses the critical issue of removing the code duplication currently
present in the MySQL, ODBC and Postgres indexers (btw: the contributed ODBC
code coexists seamlessly with the existing codebase; it's just a matter of
using the appropriate ./configure switch.)

Jim's proposal of using #ifdefs looks like a good starting point to me: it
unifies the codebase at relatively little expense. In the longer term, we
could replace such #ifdefs by function calls embodying a true access method

Alternatively, we could skip using #ifdefs and abstract out the
dbms-independent code directly, replacing the current calls to
{MySQL|ODBC|Postgres} API's by extern function calls. Again, the collection
of such extern functions would constitute the access method API.

I'm typing this off the top of my head, but my intuition tells me the latter
refactoring is probably the best way to go...

Best regards,

  [alchemistically shuffling his schedule wondering how to accommodate this]