Обсуждение: datetime

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dariusz
Sent: Friday, March 15, 2002 10:52 AM
To: pgsql-jdbc@postgresql.org
Subject: [JDBC] datetime

Hi,

I use JDBC interface to connect to PostgresSQL 6.5 database. When I try to access column of 'datetime' type I get error message:

"no class found for datetime". What's wrong?

Viacheslav Tararin found an error where the driver was not correctly
handling multiple errors on the same connection. I have modified
QueryExecuter so that it now will simply accumulate errors on the
backend until the protocol has finished, and then throw the exception.

I have updated the jar on the download site as well.

I have also done a little more work on the logging mechanism. You can
now specify the logLevel with

org.postgresql.Driver.setLogLevel(DEBUG,INFO,WARN,ERROR,FATAL)

I'm loath to start sprinking debugging messages around, since it will
only slow the driver down. But the mechanism is there

Cheers,

Dave

Hello again.

Dave Cramer wrote:

> Viacheslav Tararin found an error where the driver was not correctly
> handling multiple errors on the same connection. I have modified
> QueryExecuter so that it now will simply accumulate errors on the
> backend until the protocol has finished, and then throw the exception.
>
> I have updated the jar on the download site as well.
>
> I have also done a little more work on the logging mechanism. You can
> now specify the logLevel with
>
> org.postgresql.Driver.setLogLevel(DEBUG,INFO,WARN,ERROR,FATAL)
>
> I'm loath to start sprinking debugging messages around, since it will
> only slow the driver down. But the mechanism is there


That's why I always thought that java should have come with a
preprocessor.  Then you could easily provide 2 versions of the driver,
one with built in logs and another free of any logging code.
Preprocessing is great for adding debuging features to a code.

I know, I know, people can shoot themselves with preprocessing.  So let
them do so... but do not hold out a feature because of this...  (hear
this Sun?)

My 2 cents. ;)
Hans

A number of people have asked about logging in the driver, and
specifically about the use of log4j.

There are a number of issues with this.

1) It means that we have to have another jar, and likely include in the
distribution. For folks that don't use java this is a burden. Think of
it this way, do you want to download a bunch of perl modules with the
driver so you can use jdbc?

2) log4j uses a propery file to load it's configuration and it seems
there are some *very* creative ways to load database drivers out there
which do not load the log4j properties correctly.

3) Regardless of how fast log4j is or isn't it is still will slow the
driver down. And as Hans pointed out java has no preprocessing so we
either get logging in there or not.

4) log4j does facilitate changing the loglevel at runtime instead of
compile time, but we still run into issues where we have to create a
string object to log whereas now we don't so code like:

    foo(getInfofrombackend())

Becomes

    String msg = getInfofrombackend();
    logger.debug(msg);
    foo(msg);

So the question is:

Do we want to put logging in the driver?
Why?
How much?
At what cost?

I have given some thought to question 1) above and we could use a
pluggable logger so that log4j could be used if configured or, there
would be a default logger. However this would only slow things down even
more.

Dave

I would vote no on mandatory driver logging.  Maybe one could construct a
comment based stub which would have a utility run against the code to include
the debugging code much like a real pre-compiler. This seems problematical
and less desirable IMHO to just dealing with the logs in the backend
for support purposes. By default I would hope the driver is not burdened
extensive and expensive logging code. I guess it depends on what
a persons need is. I prefer the simplicity we have now. Of course I am
not a source contributor so I may be out of line in my suggestions.

BTW, if driver logging was included I would probably stay on the previous
release and eventually write a utility to strip it out especially if it
required
a bunch of  perl modules. I went to java servlets to be rid of perl. Perl may
be fun to write and I like it personally but it is too wierd for many in my
organization.

Just one voice.

At 04:15 PM 3/16/2002 -0500, Dave Cramer wrote:
>A number of people have asked about logging in the driver, and
>specifically about the use of log4j.
>
>There are a number of issues with this.
>
>1) It means that we have to have another jar, and likely include in the
>distribution. For folks that don't use java this is a burden. Think of
>it this way, do you want to download a bunch of perl modules with the
>driver so you can use jdbc?
>
>2) log4j uses a propery file to load it's configuration and it seems
>there are some *very* creative ways to load database drivers out there
>which do not load the log4j properties correctly.
>
>3) Regardless of how fast log4j is or isn't it is still will slow the
>driver down. And as Hans pointed out java has no preprocessing so we
>either get logging in there or not.
>
>4) log4j does facilitate changing the loglevel at runtime instead of
>compile time, but we still run into issues where we have to create a
>string object to log whereas now we don't so code like:
>
>         foo(getInfofrombackend())
>
>Becomes
>
>         String msg = getInfofrombackend();
>         logger.debug(msg);
>         foo(msg);
>
>So the question is:
>
>Do we want to put logging in the driver?
>Why?
>How much?
>At what cost?
>
>I have given some thought to question 1) above and we could use a
>pluggable logger so that log4j could be used if configured or, there
>would be a default logger. However this would only slow things down even
>more.
>
>Dave
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html

Where can I find java source code for the postgresql driver(s)?

Where can I find documentation on jdbc Serialize (not java.io.Serialize)?

Is there a jdbc3.0 driver available for postgresql?

Thanks

Charlie Kelly

Well FWIW I tend to agree, there is already logging in the backend, so
I'm not sure of the value add for putting logging in the driver.

Just to clarify my reference to the perl modules, it was an example. I
certainly don't intend to add perl modules to the jdbc driver. If
anything, preprocessing could be accomplished using ant as in
Driver.java.in, or by modifying the binary directly.

Both of the above solutions are far from perfect though.

Dave

> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Peter V Cooper
> Sent: Sunday, March 17, 2002 12:34 PM
> To: Dave@micro-automation.net; pgsql-jdbc@postgresql.org
> Cc: 'Bruce Momjian'
> Subject: Re: [JDBC] JDBC Logging & log4j
>
>
> I would vote no on mandatory driver logging.  Maybe one could
> construct a comment based stub which would have a utility run
> against the code to include the debugging code much like a
> real pre-compiler. This seems problematical and less
> desirable IMHO to just dealing with the logs in the backend
> for support purposes. By default I would hope the driver is
> not burdened extensive and expensive logging code. I guess it
> depends on what a persons need is. I prefer the simplicity we
> have now. Of course I am not a source contributor so I may be
> out of line in my suggestions.
>
> BTW, if driver logging was included I would probably stay on
> the previous release and eventually write a utility to strip
> it out especially if it
> required
> a bunch of  perl modules. I went to java servlets to be rid
> of perl. Perl may be fun to write and I like it personally
> but it is too wierd for many in my organization.
>
> Just one voice.
>
> At 04:15 PM 3/16/2002 -0500, Dave Cramer wrote:
> >A number of people have asked about logging in the driver, and
> >specifically about the use of log4j.
> >
> >There are a number of issues with this.
> >
> >1) It means that we have to have another jar, and likely
> include in the
> >distribution. For folks that don't use java this is a
> burden. Think of
> >it this way, do you want to download a bunch of perl modules
> with the
> >driver so you can use jdbc?
> >
> >2) log4j uses a propery file to load it's configuration and it seems
> >there are some *very* creative ways to load database drivers
> out there
> >which do not load the log4j properties correctly.
> >
> >3) Regardless of how fast log4j is or isn't it is still will
> slow the
> >driver down. And as Hans pointed out java has no preprocessing so we
> >either get logging in there or not.
> >
> >4) log4j does facilitate changing the loglevel at runtime instead of
> >compile time, but we still run into issues where we have to create a
> >string object to log whereas now we don't so code like:
> >
> >         foo(getInfofrombackend())
> >
> >Becomes
> >
> >         String msg = getInfofrombackend();
> >         logger.debug(msg);
> >         foo(msg);
> >
> >So the question is:
> >
> >Do we want to put logging in the driver?
> >Why?
> >How much?
> >At what cost?
> >
> >I have given some thought to question 1) above and we could use a
> >pluggable logger so that log4j could be used if configured or, there
> >would be a default logger. However this would only slow things down
> >even more.
> >
> >Dave
> >
> >
> >---------------------------(end of
> >broadcast)---------------------------
> >TIP 5: Have you checked our extensive FAQ?
> >
> >http://www.postgresql.org/users-lounge/docs/faq.html
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an
> appropriate subscribe-nomail command to
> majordomo@postgresql.org so that your message can get through
> to the mailing list cleanly
>
>

Charlie,

The source code is on cvs.postgresql.org. have a look at the developer
docs for anon cvs access

Documentation for jdbc Serialize is in the docs found at
www.postgresql.org in the interface section at the bottom

No jdbc3.0 driver is not available at the moment

Dave

> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Charlie Kelly
> Sent: Sunday, March 17, 2002 2:47 PM
> To: Peter V Cooper
> Cc: Dave@micro-automation.net; pgsql-jdbc@postgresql.org
> Subject: [JDBC] Newbie Questions
>
>
> Where can I find java source code for the postgresql driver(s)?
>
> Where can I find documentation on jdbc Serialize (not
> java.io.Serialize)?
>
> Is there a jdbc3.0 driver available for postgresql?
>
> Thanks
>
> Charlie Kelly
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
http://www.postgresql.org/users-lounge/docs/faq.html

Hello Dave,

DC> A number of people have asked about logging in the driver, and
DC> specifically about the use of log4j.

You can use Avalon framework, for allowing to use user defined logging
tool.

--
Best regards,
 Viacheslav                            mailto:taras@dekasoft.com.ua

Whew, I prefer what we have as the logging is already done to a file
on the backend and having run a support organization with many
hundreds of users under oracle the common log file on the server
seems just great. That is what is needed for my support purposes.
Maybe there are other uses. I'd prefer not to need to know ant that
much either. If we could have a build flag which would add the
logging in the driver that might be fine to get logging in the driver.
I still have to question why the backend log is insufficient.

At 02:51 PM 3/17/2002 -0500, Dave Cramer wrote:
>Well FWIW I tend to agree, there is already logging in the backend, so
>I'm not sure of the value add for putting logging in the driver.
>
>Just to clarify my reference to the perl modules, it was an example. I
>certainly don't intend to add perl modules to the jdbc driver. If
>anything, preprocessing could be accomplished using ant as in
>Driver.java.in, or by modifying the binary directly.
>
>Both of the above solutions are far from perfect though.
>
>Dave
>
> > -----Original Message-----
> > From: pgsql-jdbc-owner@postgresql.org
> > [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Peter V Cooper
> > Sent: Sunday, March 17, 2002 12:34 PM
> > To: Dave@micro-automation.net; pgsql-jdbc@postgresql.org
> > Cc: 'Bruce Momjian'
> > Subject: Re: [JDBC] JDBC Logging & log4j
> >
> >
> > I would vote no on mandatory driver logging.  Maybe one could
> > construct a comment based stub which would have a utility run
> > against the code to include the debugging code much like a
> > real pre-compiler. This seems problematical and less
> > desirable IMHO to just dealing with the logs in the backend
> > for support purposes. By default I would hope the driver is
> > not burdened extensive and expensive logging code. I guess it
> > depends on what a persons need is. I prefer the simplicity we
> > have now. Of course I am not a source contributor so I may be
> > out of line in my suggestions.
> >
> > BTW, if driver logging was included I would probably stay on
> > the previous release and eventually write a utility to strip
> > it out especially if it
> > required
> > a bunch of  perl modules. I went to java servlets to be rid
> > of perl. Perl may be fun to write and I like it personally
> > but it is too wierd for many in my organization.
> >
> > Just one voice.
> >
> > At 04:15 PM 3/16/2002 -0500, Dave Cramer wrote:
> > >A number of people have asked about logging in the driver, and
> > >specifically about the use of log4j.
> > >
> > >There are a number of issues with this.
> > >
> > >1) It means that we have to have another jar, and likely
> > include in the
> > >distribution. For folks that don't use java this is a
> > burden. Think of
> > >it this way, do you want to download a bunch of perl modules
> > with the
> > >driver so you can use jdbc?
> > >
> > >2) log4j uses a propery file to load it's configuration and it seems
> > >there are some *very* creative ways to load database drivers
> > out there
> > >which do not load the log4j properties correctly.
> > >
> > >3) Regardless of how fast log4j is or isn't it is still will
> > slow the
> > >driver down. And as Hans pointed out java has no preprocessing so we
> > >either get logging in there or not.
> > >
> > >4) log4j does facilitate changing the loglevel at runtime instead of
> > >compile time, but we still run into issues where we have to create a
> > >string object to log whereas now we don't so code like:
> > >
> > >         foo(getInfofrombackend())
> > >
> > >Becomes
> > >
> > >         String msg = getInfofrombackend();
> > >         logger.debug(msg);
> > >         foo(msg);
> > >
> > >So the question is:
> > >
> > >Do we want to put logging in the driver?
> > >Why?
> > >How much?
> > >At what cost?
> > >
> > >I have given some thought to question 1) above and we could use a
> > >pluggable logger so that log4j could be used if configured or, there
> > >would be a default logger. However this would only slow things down
> > >even more.
> > >
> > >Dave
> > >
> > >
> > >---------------------------(end of
> > >broadcast)---------------------------
> > >TIP 5: Have you checked our extensive FAQ?
> > >
> > >http://www.postgresql.org/users-lounge/docs/faq.html
> >
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an
> > appropriate subscribe-nomail command to
> > majordomo@postgresql.org so that your message can get through
> > to the mailing list cleanly
> >
> >

----- Original Message -----
From: "Dave Cramer" <Dave@micro-automation.net>
Sent: Saturday, March 16, 2002 4:15 PM

> Do we want to put logging in the driver?
> Why?
> How much?
> At what cost?

Needless to say, logging is essential thing to have,
but to answer the above questions one answer could be - to try.
If those who care about the logging facilities, could
simply mirror current dev. tree of the driver, and some in,
and compare performance between the two on the same set of
tests.

Another possible solution just came into my not-always-so-smart-head,
is to write some pre-processing ourselves :). Put some special types
of comments in the places where the logging seems appropriate like:

//{DEBUG

logSmthHere();

//}DEBUG

Just a simple {PERL, Shell, Python, whatever}-script may run through the sources
and produce two jars, one compiled with DEBUG as it is, the other
one will be a stripped out //{DEBUG version. Yes, I know this will require
some tmp space and some extra processing, but could be a solution too.

2 Canadian cents

-s

Sergui,

Actually I think I like this option and all that is really required is
something like

//DEBUG    Driver.debug(message)

Then it would compile properly and if you wanted you could enable the
debug statements with a regex of some sort

Dave

> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Serguei Mokhov
> Sent: Saturday, March 16, 2002 4:40 PM
> To: Dave@micro-automation.net; pgsql-jdbc@postgresql.org
> Cc: 'Bruce Momjian'
> Subject: Re: [JDBC] JDBC Logging & log4j
>
>
> ----- Original Message -----
> From: "Dave Cramer" <Dave@micro-automation.net>
> Sent: Saturday, March 16, 2002 4:15 PM
>
> > Do we want to put logging in the driver?
> > Why?
> > How much?
> > At what cost?
>
> Needless to say, logging is essential thing to have,
> but to answer the above questions one answer could be - to
> try. If those who care about the logging facilities, could
> simply mirror current dev. tree of the driver, and some in,
> and compare performance between the two on the same set of tests.
>
> Another possible solution just came into my
> not-always-so-smart-head, is to write some pre-processing
> ourselves :). Put some special types of comments in the
> places where the logging seems appropriate like:
>
> //{DEBUG
>
> logSmthHere();
>
> //}DEBUG
>
> Just a simple {PERL, Shell, Python, whatever}-script may run
> through the sources and produce two jars, one compiled with
> DEBUG as it is, the other one will be a stripped out //{DEBUG
> version. Yes, I know this will require some tmp space and
> some extra processing, but could be a solution too.
>
> 2 Canadian cents
>
> -s
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to
> majordomo@postgresql.org)
>
>