Re: [Tcl-tdbc] Slowly (VERY slowly) writing Tdbc driver for Sybase

[Kevin K. <ke...@ac...>]

hyt...@gm... wrote:
> First, this is something I'm doing on my free time as a learning
> exercise--which is a couple of hours a week if I'm lucky--so if
> anybody is already doing it please cut in and spare me the trouble :)

To the best of my knowledge, nobody is working on a Sybase driver,
which if done right would also provide the foundations of a native
SQL Server driver.

> The plan:
> - Develop against the ctlib distributed with ASE 15's x86 distro,
> using Visual C++ Express 2008.  I'll provide both an nmake makefile
> and the express's project file.

OK as far as it goes.  We'll probably also want a mingw equivalent,
but someone else can handle the port once the base is done.

> - Keeping FreeTDS in mind, try (if possible) to stick with only the
> ctlib routines actually supported by the latest stable FreeTDS distro.
 > - Stick with Sybase 10's TDS, for backwards compatibility.

That's fine, too. TBDC uses prety vanilla stuff, I doubt it needs
anything that isn't "lowest common denominator"

> - Use Sybase' pub* databases for accompanying unit test code.

Uhm. Ok. If you look at the test suites for the three drivers
now in existence, they all start with an empty database and
do their own CREATE TABLE statements.  Of course, there's no
need for the database to be empty, as long as the created tables
don't collide with stuff that's already there. The three test
suites borrow large amounts of code (and the test numbers) from
each other, and I'd kind of like to keep the tests as uniform
as possible. But use your judgment.

> - No support for DBLib.  At all.

I remember DBLib. With no particular affection.

> What I'm concerned about:
> - Null handling.  This seems to be an  open question.  Any particular
> reason why this can't be a method in one of the TDBC objects (e.g.,
> the resultset)?

TIP 308 defines the semantics of NULL quite explicitly and is
consistent about it. The only 'open question' is what to do about
the incessant complaints from a few users who don't agree with
it.

> - Big/Little Endian concerns, especially when working across different
> platforms.   I'm not sure how seamless this is and how much I have to
> do on my own..

I presume you mean with the database API?  Tcl hides endianity
from you, and I seem to recall that TDS does as well.

> - Internationalization.  I think Sybase has a Japanese pub, but I
> don't read Japanese so I'm kind of stuck there :)

Tcl's internal character representation is UTF-8. If you can
configure the API so that strings are UTF-8 throughout, you're
home free.  Otherwise, Tcl has a rich encoding conversion system,
and we *do* have users who are literate in Japanese (Chinese,
Korean, etc.) who can advise and check you.

> Hopefully, the developers manual will answer most of my questions and
> concerns.

Thanks for taking this on, and welcome aboard!  I'm very glad to have
you with us.  I suggest a few things:

    - Subscribe to the 'tcl-tdbc' mailing list at SourceForge and
      ask questions there.  It's *very* low volume, don't be afraid
      to join.
    - Get TIPs 308 (http://tip.tcl.tk/308) and 350
      (http://tip.tcl.tk/350) and try to understand them. They
      go into considerable detail about the API that a driver
      needs to present.
    - Go to http://tdbc.tcl.tk/, login as 'anonymous' with the
      password that appears on the login page, and follow the
      instructions to download the source ZIP. The source code
      for the ODBC and MySQL drivers should give a decent idea
      what is to be implemented. There are also comments in
      tdbc/library/tdbc.tcl about what methods a driver needs
      to support.
    - Look through the test suites of the drivers.  It's useful
      to develop a piece at a time, with the goal to get more
      tests working at each stage. The test suites are structured
      around this idea; the earliest tests are "easy" (requiring
      only opening/closing database connections), and then they
      get "harder" as you go along.  I suggest initially treating
      all database values as character strings and deferring
      data-type specific conversions to the very end of the
      development cycle.

Let me know if you need help!

-- 
73 de ke9tv/2, Kevin