pgjdbc-ng | new JDBC driver for PostgreSQL | DB Client library

by impossibl Java Version: 0.7.0-7d96678 License: Non-SPDX

X-Ray Key Features Code Snippets Community Discussions(3)Vulnerabilities Install Support

kandi X-RAY | pgjdbc-ng Summary

pgjdbc-ng is a Java library typically used in Utilities, DB Client applications. pgjdbc-ng has no bugs, it has no vulnerabilities and it has high support. However pgjdbc-ng build file is not available and it has a Non-SPDX License. You can download it from GitHub, Maven.

A new JDBC driver for PostgreSQL aimed at supporting the advanced features of JDBC and Postgres

Support

Quality

Security

License

Reuse

Support

pgjdbc-ng has a highly active ecosystem.

It has 568 star(s) with 107 fork(s). There are 40 watchers for this library.

It had no major release in the last 12 months.

There are 41 open issues and 263 have been closed. On average issues are closed in 207 days. There are 11 open pull requests and 0 closed requests.

It has a positive sentiment in the developer community.

The latest version of pgjdbc-ng is 0.7.0-7d96678

Quality

pgjdbc-ng has 0 bugs and 0 code smells.

Security

pgjdbc-ng has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

pgjdbc-ng code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

pgjdbc-ng has a Non-SPDX License.

Non-SPDX licenses can be open source with a non SPDX compliant license, or non open source licenses, and you need to review them closely before use.

Reuse

pgjdbc-ng releases are available to install and integrate.

Deployable package is available in Maven.

pgjdbc-ng has no build file. You will be need to create the build yourself to build the component from source.

Installation instructions are not available. Examples and code snippets are available.

It has 63595 lines of code, 6082 functions and 436 files.

It has medium code complexity. Code complexity directly impacts maintainability of the code.

Top functions reviewed by kandi - BETA

kandi has reviewed pgjdbc-ng and discovered the below as its top functions. This is intended to give you an instant insight into pgjdbc-ng implemented functionality, and help decide if they suit your requirements.

Maps a given codepoint from a given codepoint .
Get JDBC type from value .
Retrieves the properties of a procedure .
Parse an IPv6 address .
Parse a connection spec from a URL .
Parse and dispatch a handler .
Updates the system parameter with the given value .
Returns the private key for the specified alias .
Parses server address .
Convert string to SASl format .

Get all kandi verified functions for this library.

pgjdbc-ng Key Features

No Key Features are available at this moment for pgjdbc-ng.

pgjdbc-ng Examples and Code Snippets

No Code Snippets are available at this moment for pgjdbc-ng.

Community Discussions

Trending Discussions on pgjdbc-ng

Is it a good idea to close the JDBC connection in case of PG Listen/Notify polling?

How do I configure HikariCP correctly to work with connections that have to stay active?

How to get Camel PgEvent component to use DataSource properly in Java Spring

QUESTION

Is it a good idea to close the JDBC connection in case of PG Listen/Notify polling?

Asked 2022-Mar-08 at 04:35

We use connection pool in our application. While I understand that we should close and get connections as needed since we are using a connection pool. I implemented a cache update mechanism by receiving Postgres LISTEN notifications. The code is pretty much similar to the canonical example given by the documentation.

As you can see in the code, the query is initiated in the constructor and the connection is re used. This may pose problem when the connection is closed out of band due to any factor. One solution to this is to get the connection before every use, but as you can see the statement is only executed once in the constructor but still I can receive the notification in the polling. So if I get the connection every time, it will force me to re issue the statement for every iteration(after delay). I'm not sure if that's an expensive operation.

What is the middle ground here?

...

ANSWER

Answered 2022-Mar-08 at 03:01

The connection pool is the servant, not the master. Keep the connection for as long as you are using it to LISTEN on, i.e. ideally forever. If the connection ever does close, then you will miss whatever notices were sent while it was closed. So to keep the cache in good shape, you would need to discard the whole thing and start over. Obviously not something you would want to do on a regular basis, or what would be the point of having it in the first place?

The other doc you show is just an ancient version of the first one. The dummy query just before polling is there to poke the underlying socket code to make sure it has absorbed all the messages. This is no longer necessary. I don't know if it ever was necessary, it might have just been some cargo cult that found its way into the docs.

You would probably be better off with the blocking version of this code, by using getNotifications(0) and getting rid of sleep(delay). This will block until a notice becomes available, rather than waking up twice a second and consuming some (small) amount of resources before sleeping again. Also, once a notice does arrive it will be processed almost immediately, instead of waiting for what is left of a half-second timeout to expire (so, on average, about a quarter second).

Source https://stackoverflow.com/questions/71383619

QUESTION

How do I configure HikariCP correctly to work with connections that have to stay active?

Asked 2021-Apr-23 at 06:31

I am using Spring Boot 2.4.0 with Spring Boot Data JPA to connect to PostgreSQL and perform typical read and write operations with JPA based repositories. Since the database is also used by other services, I use the LISTEN/NOTIFY functionality (https://www.postgresql.org/docs/9.1/sql-listen.html) to be notified about changes from PostgeSQL. For this I use the driver com.impossibl.postgres.jdbc.PGDriver instead of the default driver and the following code to make Spring listen for changes to the database:

...

ANSWER

Answered 2021-Apr-23 at 06:31

Not the same issue, but I had a similar problem. When my database was restarted, Hikari couldn't close the active listener connection, and the whole notification stopped working.

I found a possible solution for this. The reason why Hikari can't close the connection when it's dead because you are unwrapping the connection from the proxied Connection here:

Source https://stackoverflow.com/questions/66455301

QUESTION

How to get Camel PgEvent component to use DataSource properly in Java Spring

Asked 2020-Nov-13 at 13:22

I am using Apache Camel on Spring Boot and want a route to listen to PostgreSQL notify calls.

Camel version: 3.4.4
Spring Boot version: 2.3.3

I have tried using the PgEvent component from Camel, but have found the documentation quite lacking when you want to use a DataSource object to fill in the database specifics (i.e. url, username, password). I have neither found any examples of working solutions in stackoverflow, nor around the web.

Below are some sources I found helpful:

In the end, the "normal" jdbc:postgresql:/... url I was using did not work. So I followed the linked SO-answer, suggesting using the pgjdbc-ng driver (my colleague suggested the same). Following the documentation of the second link I found that my Camel route started working. All I needed to do was change the previous DataSource url to jdbc:pgsql:/....

Hope this helps other people with similar problems. Wasted all too many hours on this little problem.

...

ANSWER

Answered 2020-Nov-13 at 13:22

I'm copying my own solution from the question into the answer section, as it may help others find the solution when the question is marked solved. Below is the copy of the final solution:

In the end, the "normal" jdbc:postgresql:/... url I was using did not work. So I followed the linked SO-answer, suggesting using the pgjdbc-ng driver (my colleague suggested the same). Following the documentation of the second link I found that my Camel route started working. All I needed to do was change the previous DataSource url to jdbc:pgsql:/....

Source https://stackoverflow.com/questions/64445026

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install pgjdbc-ng

You can download it from GitHub, Maven.
You can use pgjdbc-ng like any standard Java library. Please include the the jar files in your classpath. You can also use any IDE and you can run and debug the pgjdbc-ng component as you would do with any other Java program. Best practice is to use a build tool that supports dependency management such as Maven or Gradle. For Maven installation, please refer maven.apache.org. For Gradle installation, please refer gradle.org .

Support

For any new features, suggestions and bugs create an issue on GitHub. If you have any questions check and ask questions on community page Stack Overflow .

Find more information at: