FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

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