Skip to Content.
Sympa Menu

freetds - Re: [freetds] New upcoming release, branch, rc and others...

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] New upcoming release, branch, rc and others...
  • Date: Tue, 8 Jan 2008 10:59:21 -0500

ZIGLIO, Frediano, VF-IT wrote:
> I think is time for a RC... step are usually
> 1- cvs tag -b BRANCH0_XX (should be cvs tag -b BRANCH0_82, Am I right?)
> 2- update configure.ac changing version to 0.82rc1
> 3- update userguide.sgml
> 4- package, publish and announce new version
>
> I can manage steps 1 to 3 by myself.

Excellent. I've been waiting to hear you say you're ready. I didn't want
to branch a release while you were in the middle of a bunch of changes.

Please go ahead and branch BRANCH0_82. Yay!

One thing I'd like to do first. You truncated ChangeLog and moved the
2007 updates to another file. I think our year-by-year scheme isn't that
good. Instead, let's have a release-by-release scheme.

ChangeLog: changes in CVS HEAD since the last release
ChangeLog-0.82: changes since 0.64
ChangeLog-0.64: changes since 0.63
etc.

We don't have to go back and recreate all the old ones. But I think it
would be good to create ChangeLog-0.82 now.

> It's also a good time to start planning for next release!
>
> Ideas/big TODOs:
> - support for mssql 2005 (MARS, varchar(max) and so on)
> - wide characters in ODBC
> - refactor Makefiles using GNU make
> - refactor token.c splitting token handling from upper managing
> - improve multiple request support by libTDS and upper layer
> - limit copy of data

Good ideas all, except I want to continue to support BSD make. I don't
see any reason not to.

> As you can note I have no plans for dblib/ctlib

I do, but I'm not sure when I'll get around to it.

BLOB handling is a problem. We make too many copies. It doesn't matter
with normal columns, but BLOBs can exhaust virtual memory.

bcp_moretext is the last essential bcp feature. locale and bcp still
needs some attention, too.

I hope the splitting out the token handling leads to a more rational API
for libtds. I really don't like the bitwise OR flags to tell it when to
return.

> - limit copy of data

An idea about allocation.

In db-lib -- I don't know if ODBC has a similar feature -- data can be
fetched with bound columns (dbbind) or not (dbdata). For bound columns,
the client allocates a buffer for the data. When libtds fetches a row, it
needs to allocate buffers only for unbound columns. (That's not *quite*
true. If the bound buffer is too small, libtds has to allocate enough
space for the rest of it. dbdata should work correctly even if dbbind
allocated too small a buffer.)

We want to make client-allocated buffers available to libtds. That will
avoid copying kernel->libtds->client.

Regards,

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page