FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

On Fri, 23 Jun 2000, Scott C. Gray wrote:

> 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.
> 

I'd like to recommend that we tag a version from CVS and if there are no
huge bugs call it '0.60'.  We haven't had a release in forever anyway.  Then
we can start tearing things up with my blessing.

Some of the things in the TDS layer are getting long in the tooth.  They
were put in place long before I had a clue about how things worked. 

I'm going to disagree about conversion not belonging in the TDS layer
however.  What tds_convert converts is the server datatype as given in the
result set.  Each CLI handles converting between its type and the server
type.  Regardless of what ctlib, dblib, or ODBC calls it, it is the
server that assigns the datatype.  So having 3 ways of converting SYBINT4 to
SYBCHAR is a bit redundant.

Perhaps, what we really need is the equivalent of libcomn to do these types
of shared functionality.  I'll happily fix dblib to work over the new
underpinnings when I have the time. (We close on Wednesday for the
house....this has been going on for 3 months since we put the offer in!)

Brian

> [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
> 
> 
> ---
> You are currently subscribed to freetds as: camber AT ais.org
> To unsubscribe, forward this message to $subst('Email.Unsub')
> 
>