Skip to Content.
Sympa Menu

freetds - RE: big changes, conversion fixes, and tds_willconvert

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: ZIGLIO Frediano <Frediano.Ziglio AT vodafoneomnitel.it>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: RE: big changes, conversion fixes, and tds_willconvert
  • Date: Mon, 15 Jul 2002 12:19:20 +0200


>
> Hi all,
>
> I've just checked in some fairly substantial changes to CVS, based
> largely off of Frediano's patch, but reworked a bit by moi.

Wow.. I never tough this patch was so important to be included in 0.6
version

> As discussed
> in the thread with Bill about conversions, each API now has a
> TDSCONTEXT
> pointer which maintains a few important items. This should
> allow us to
> modify the handler routines to deal with the lack of a socket
> structure
> (dbproc, cs_conn, hdbc).
>
> The locale structure is now pointed to by the TDSCONTEXT
> structure and is
> automatically allocated and read during tds_alloc_context().
> tds_connect
> now needs a valid context passed to it instead of a TDSLOCINFO.
>
> I haven't made all the handler changes yet that I need to,
> specifically
> API handlers should do some logic that is a bit like this:
>
> if (tds_socket) {
> ...
> call the per socket handler if any with tds->msg_info,
> else call the context wide handler with tds->msg_info
> } else {
> call the context wide handler with context->msg_info
> }
>

I think this is not good. context mantain information per library, msg_info
is not per library (but can be per socket). First strange thing I note in
patch was msg_info in TDSCONTEXT.

> this will allow tds_client_msg() to be called during
> conversion without a
> socket structure, in accordance with dblib/ctlib specs. My
> big question
> is that the two threads calling dbconvert simultaneously
> encounter errors
> context->msg_info may be overwritten, and the application may
> receive the
> same error twice on different threads. Not exactly sure how
> to deal with
> that one yet.
>

Perhaps best solution is to pass to libraries two parameters
message(TDSSOCKET* ,TDSMSGINFO*), (TDSCONTEXT can be retrieved from
TDSSOKET). Added library information per socket can be retrieved by
tds_socket->parent.
I think library must be full-multithreaded for socket (I cannot read from a
socket from 2 thread).

> Anyway, beware of CVS over the next couple of days, as this is a big
> reconoitering and I've still got some work to do yet. All
> the unittests
> programs do pass though (with the exception of most of the
> dblib ones for
> reasons stated below) so we hopefully didn't mung things up
> too badly.

Mmmm...
- tds all work (I have also written some fix for problem deleted unexisting
table or other see patch #580272)
- none of ctlib work (see patch #581224 for fix all)
- none of dblib work (see patch #581224 and also as stated below fix calling
to tds_willconvert in dbbind and 17 of them work)

> Note, this is a libtds api change for those working directly
> with libtds!
> Stay tuned.
>
> The other problem is with the implementation of
> dbwillconvert. Jim, you
> got to convert those dblib types to server types before
> sending them to
> tds_willconvert. dbbind also calls dbwillconvert() directly
> and instead
> should be calling tds_willconvert because it shouldn't be
> making the trip
> from servertype -> dblib type -> servertype. I just stumbled
> on this one
> and haven't had a chance to fix it, and it doesn't look good
> for tonight.
> So, the dblib unittests mostly fail on dbbind until further notice.
>
...
>
> Jim, I'd say we give 0.60 a couple more weeks to solidify, having the
> conversion/binding stuff rock solid would be worth the wait, IMO.
>
> Brian
>
I think so...

freddy77

PS: I'm glad if someone can check patch #580072 (IMHO another required patch
for 0.6)

=================================
"STRICTLY PERSONAL AND CONFIDENTIAL

This message may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
The contents of this message that do not relate to the official business of
our company shall be understood as neither given nor endorsed by it."

=================================




Archive powered by MHonArc 2.6.24.

Top of Page