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: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] New upcoming release, branch, rc and others...
  • Date: Tue, 8 Jan 2008 17:28:22 +0100

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

I mainly split between years cause committing ChangeLog every time was
starting to be a nightmare...
I don't know if automake require a ChangeLog but I think we can put a
"See ChangeLog-xxxx" line...

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

Is that I don't know if BSD make have some extension that could make
no-recursive make easy to develop.

I found a good way to have customizations within directory. Using GNU
make you can have things like

src/odbc/unittests/% : CPPFLAGS += -I$(ODBC_INC)

that is: if target is in directory src/odbc/unittests add -I$(ODBC_INC)
to CPPFLAGS !! Simple and working!!

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

I know...

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

Mmm... a question... does dbdata work if dbbind is used?? If yes you
always have to buffer result...

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

Yes, usually referred as zero-copy :)

bye
freddy77




Archive powered by MHonArc 2.6.24.

Top of Page