Skip to Content.
Sympa Menu

freetds - RE: [freetds] Longstanding issue and 0.64...

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Longstanding issue and 0.64...
  • Date: Mon, 29 Nov 2004 14:03:27 -0500

> From: ZIGLIO, Frediano, VF-IT
> Sent: Monday, November 29, 2004 10:16 AM
>
> Now that we are more free I would like to discuss some longstanding
> (big) changes. Mainly logging, thread-safe and row structure!
>
> Log:
> - James open the question many time ago. If would be fine to filter
> logs by type (network, data and so only) and not only on level
> - log it's mainly global. Although you can configure log by
connection
> a new connection just override all opened logs (not that kind). This
> make logging global and cause some problems for testing (setting log
for
> a connection cause logging for entire server). Also there is a small
> memory leak allocating name of logging file. This will require to put
> logging file name in TDSSOCKET and an additional TDSSOCKET* parameter
to
> logging functions

I'd like the log to be opened once, when the library is initialized,
unless we make the once-per-pid behavior standard.

I think the log format should be standardized; it would be easier to
grep and scan. I don't see much value in logging the time on every
line. It's enough that we know when packets were sent and received.

Here's a format suggestion:

LEVEL PID Function (File:Line): text

LEVEL would be one of:

LOGIN
API
ASYNC
DIAG
ERROR
PACKET
LIBTDS
CONFIG

Continuations of "text" would appear on succeeding lines, starting with
a tab character.

> (perhaps we need also to syncronize access to a single file)

Surely stdio synchronizes writes to a file?

> - it would be fine to be able to disable compile of logging code for
> embedded systems

Right. If tdsdump() were called in the code via a macro, "TDSDUMP()",
we could defeat logging with a #define. But are there any embedded
systems?

> Thread-safe:
> - cancel function can be called from other thread or from signal...
we
> have to handle both situations safety...

I don't think FreeTDS should catch signals. It's up to the application
to catch signals and call the API accordingly. If we decide to use
O_ASYNC, that's another story.

> Row structure:
> - well there is few things to say. It's a shit! We did too job to use
> the same packing method used for getting data and in some case we lose
> IMHO too much memory. All library use to bind parameters for input so
it
> would be good to use these bindings and compute row on the fly. This
for
> rpc/dynamic sql/bcp and if possibly while reading data.

We need to support binary bindings of character data. We lost that
feature when we implemented iconv throughout.

--jkl

-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the original
message. Please note that we do not accept account orders and/or instructions
by e-mail, and therefore will not be responsible for carrying out such orders
and/or instructions.
If you, as the intended recipient of this message, the purpose of which is to
inform and update our clients, prospects and consultants of developments
relating to our services and products, would not like to receive further
e-mail correspondence from the sender, please "reply" to the sender
indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New York,
NY 10105.






Archive powered by MHonArc 2.6.24.

Top of Page