FreeTDS Development Group

["Scott C. Gray" <gray AT voicenet.com>]

On Thu, 22 Jun 2000, Mark Schaal wrote:

> > 
> > 
> > Does anyone know who takes primary ownership for the 'dblib' code
> > (probably Brian, but I figured it is quickly to ask the whole list).
> 
> Brian is the owner of freetds, including the dblib code.
> 
> Changing interfaces is pretty serious.  It would be helpful if
> you posted your proposed changes.  


Fair 'nuf.

[Sorry for the length of the following...]

The major issue that I see is that the TDS layer has been hard-coded
to be "dblib friendly".  That is, it supresses many of the result sets
that are normally bubbled up through ct_results() (param results, 
and certain done results). Also, it does not allow more than one
outstanding query per TDSSOCKET*, which is required in order to
support cursors (don't get me wrong..I am not a fan of using client-side
cursors, however, many applications that currently exist do use them).

Also, there is a little awkwardness in the design.  For example,
the data-type conversion routines do not belong in the TDS layer.
And, in fact, the conversion code in the TDS layer refers to 
SYBXXXX datatypes (SYBINT4, SYBNUMERIC, etc.)...which are db-lib
symbols.  What I would like to do is to do a _complete_ cslib layer,
along with a full implementation of cs_convert() (I actually already
wrote something almost completely identical for a ct-lib look-a-like
API that I was working on a while back..it wouldn't take too long
to adapt this for use in freetds).   For the dblib library, it
could carry around a CS_CONTEXT structure under the hood to do
its data-type conversions as well.

I would also like to get rid of the TDSLOGIN structure. The only reason
that db-lib has such a beast was because the original developers at
Sybase didn't have the forsight to separate the allocation of
a connection (DBPROCESS) from the actual establishing of a connection,
so they needed a "bag" to put their configuration stuff prior to
connection.  IMHO, I think that the ct-lib model is much more elegant;
allocate the connection, configure it, then connect.

Finally, I would like to make a clearer distinction of what is
"public" in the TDS API and data structures vs. "private".  I would
like to completely hide the TDSSOCKET and its sub-structures from
view of the rest of the world and require access to happen via
API calls.  Currently, during my re-working of the TDS layer
to support cancels, I am finding that dblib calls several functions
that I don't think should be exposed, and peeks into data structures 
that could change at any time.

> Perhaps less drastic changes
> could be found, which would reduce work altering the other layers.
> Also, the ODBC guys might have comments.  I have wondered myself if
> some portions of the core might benefit from a significant rewrite,
> but never had a clear vision of what & why.

I agree. I don't like to break things.  For many of the changes
above, it should be possible to do them without _too_ much impact
except support for ct-library cursors.  In order to support this,
something along the lines of a TDS_COMMAND handle must be introduced
(mimicing the CS_COMMAND handle) that is responsible for carrying
around result set data, resinfo data, param results, etc--and thus
pulling this informatin out of the TDSSOCKET handle.  Support
for this would require some real changes to all of the higher level
libraries.

One option that I would be willing to support, would be the development
of an adapter api that would allow ODBC and dblib to remain virtually
unchanged while the TDS layer changes.  I think this will be possible
with only minor modifications to the libraries.  The only really difficult
part is to decide amongst the three libraries (ctlib, dblib, and ODBC)
what is the "public" view of the TDS library--this difficulty is
exactly why I would like to go to greater lenghts to hide the
implementation of the TDS library and document a public api, so
in the future such changes are not as painful.

Another option, would be to branch the code, and let these changes
be considered FreeTDS 2.0 while the 0.XX->1.XX branch continues
unchanged.  I prefer this option myself.


I want to make it clear that I _really_ do not want to cause anyone
headaches.  If there is a real outcry not to rock the boat too much,
I'll hold off.  But, I have a vested interest in getting ct-lib working
as well as possible (primarily against MS SQL Server--and, in fact,
I can do much of this work on business hours) and I would like to
continue to feed my changes back to the rest of the world so that
everyone can benifit.

Thanks!
-scott

--
Scott C. Gray <gray AT voicenet.com>     "my keybard is brken"
       http://www.voicenet.com/~gray/sqsh.html