Thread: [JDBC] Questions on use
PostgreSQL-9.6.1 and openjdk-8u91_b14 are installed on my Slackware-14.1 system and I am trying to use schemaSpy_5.0.0.jar on a couple of databases. I have downloaded postgresql-9.4.1212.jre6.jar but cannot get schemaSpy to run. 1) Is the -9.4.1212 version of the driver compatible with postgres-9.6.1? If not, is there a working alternative? 2) My databases are used by only me. All non-postgres-installed databases are owned by me so neither a username nor a password is required for me to access them. My login name is used by psql to allow me access. Is the lack of a password preventing the driver from functioning? If so, is there a way to inform it that no password is required here? TIA, Rich
PostgreSQL-9.6.1 and openjdk-8u91_b14 are installed on my Slackware-14.1
system and I am trying to use schemaSpy_5.0.0.jar on a couple of databases.
I have downloaded postgresql-9.4.1212.jre6.jar but cannot get schemaSpy to
run.
1) Is the -9.4.1212 version of the driver compatible with postgres-9.6.1?
If not, is there a working alternative?
Should work. The 9.4 doesn't imply server compatability.
2) My databases are used by only me. All non-postgres-installed databases
are owned by me so neither a username nor a password is required for me to
access them. My login name is used by psql to allow me access. Is the lack
of a password preventing the driver from functioning? If so, is there a way
to inform it that no password is required here?
The default for PostgreSQL is to listen on Unix sockets. JDBC doesn't talk to Unix sockets - it only uses TCP/IP sockets. You need to configure the database to listen on an IP address and port and point to that. You also need to ensure pg_hba.conf and/or have a password on the user JDBC is using (changing to "trust" might work).
David J.
PostgreSQL-9.6.1 and openjdk-8u91_b14 are installed on my Slackware-14.1
system and I am trying to use schemaSpy_5.0.0.jar on a couple of databases.
I have downloaded postgresql-9.4.1212.jre6.jar but cannot get schemaSpy to
run.
1) Is the -9.4.1212 version of the driver compatible with postgres-9.6.1?
If not, is there a working alternative?
Should work. The 9.4 doesn't imply server compatability.
2) My databases are used by only me. All non-postgres-installed databases
are owned by me so neither a username nor a password is required for me to
access them. My login name is used by psql to allow me access. Is the lack
of a password preventing the driver from functioning? If so, is there a way
to inform it that no password is required here?
The default for PostgreSQL is to listen on Unix sockets. JDBC doesn't talk to Unix sockets - it only uses TCP/IP sockets. You need to configure the database to listen on an IP address and port and point to that. You also need to ensure pg_hba.conf and/or have a password on the user JDBC is using (changing to "trust" might work).
David J.
On Wed, 28 Dec 2016, David G. Johnston wrote: > Should work. The 9.4 doesn't imply server compatability. David, Good. That's one less issue of concern. > The default for PostgreSQL is to listen on Unix sockets. JDBC doesn't > talk to Unix sockets - it only uses TCP/IP sockets. You need to configure > the database to listen on an IP address and port and point to that. You > also need to ensure pg_hba.conf and/or have a password on the user JDBC is > using (changing to "trust" might work). I modified /var/lib/pgsql/9.6/data/pg_hba.conf by adding a line with hostnossl and 'trust' as the method. Reloaded postgres. While schemaSpy still does not run the reason seems to be with it, not the driver. Many thanks, Rich
On Wed, 28 Dec 2016, David G. Johnston wrote: > Should work. The 9.4 doesn't imply server compatability. David, Good. That's one less issue of concern. > The default for PostgreSQL is to listen on Unix sockets. JDBC doesn't > talk to Unix sockets - it only uses TCP/IP sockets. You need to configure > the database to listen on an IP address and port and point to that. You > also need to ensure pg_hba.conf and/or have a password on the user JDBC is > using (changing to "trust" might work). I modified /var/lib/pgsql/9.6/data/pg_hba.conf by adding a line with hostnossl and 'trust' as the method. Reloaded postgres. While schemaSpy still does not run the reason seems to be with it, not the driver. Many thanks, Rich
On 12/28/2016 8:44 AM, Rich Shepard wrote:
>
> I modified /var/lib/pgsql/9.6/data/pg_hba.conf by adding a line with
> hostnossl and 'trust' as the method. Reloaded postgres. While schemaSpy
> still does not run the reason seems to be with it, not the driver.
verify that you can connect with
psql -h localhost -....etc....
if you can, then likely jdbc, specifying localhost and the same database
and username should be able to connect.
--
john r pierce, recycling bits in santa cruz
On 12/28/2016 8:44 AM, Rich Shepard wrote:
>
> I modified /var/lib/pgsql/9.6/data/pg_hba.conf by adding a line with
> hostnossl and 'trust' as the method. Reloaded postgres. While schemaSpy
> still does not run the reason seems to be with it, not the driver.
verify that you can connect with
psql -h localhost -....etc....
if you can, then likely jdbc, specifying localhost and the same database
and username should be able to connect.
--
john r pierce, recycling bits in santa cruz
On Wed, 28 Dec 2016, John R Pierce wrote: > verify that you can connect with > > psql -h localhost -....etc.... > > if you can, then likely jdbc, specifying localhost and the same database and > username should be able to connect. John, There's no problem from the command line, $ psql -h localhost emapw psql (9.6.1) Type "help" for help. emapw=# even without specifying the host. All I need is to generate the E-R diagrams from two databases to check for logical errors, then I'm done with it and can move to developing the rest of the applications. Thanks, Rich
On Wed, 28 Dec 2016, John R Pierce wrote: > verify that you can connect with > > psql -h localhost -....etc.... > > if you can, then likely jdbc, specifying localhost and the same database and > username should be able to connect. John, There's no problem from the command line, $ psql -h localhost emapw psql (9.6.1) Type "help" for help. emapw=# even without specifying the host. All I need is to generate the E-R diagrams from two databases to check for logical errors, then I'm done with it and can move to developing the rest of the applications. Thanks, Rich
On 12/28/2016 10:41 AM, Rich Shepard wrote: > There's no problem from the command line, > > $ psql -h localhost emapw > psql (9.6.1) > Type "help" for help. > > emapw=# > > even without specifying the host. with psql, no -h and -h localhost are two different connection types. if you don't specify a -h, it uses a 'unix domain socket', this uses the pg_hba.conf lines that start with `local`... if you DO specify -h localhost, it uses a tcp/ip socket to localhost (typically 127.0.0.1 or ::1), these match the pg_hba.conf lines that start with `host` and encompass one or the other of those networks. note that even if your system isn't using ipv6 for its network connections, it very well could be using the ipv6 localhost ::1 (shorthand for 0000:0000:0000:0000:0000:0000:0000:0001)... -- john r pierce, recycling bits in santa cruz
On 12/28/2016 10:41 AM, Rich Shepard wrote: > There's no problem from the command line, > > $ psql -h localhost emapw > psql (9.6.1) > Type "help" for help. > > emapw=# > > even without specifying the host. with psql, no -h and -h localhost are two different connection types. if you don't specify a -h, it uses a 'unix domain socket', this uses the pg_hba.conf lines that start with `local`... if you DO specify -h localhost, it uses a tcp/ip socket to localhost (typically 127.0.0.1 or ::1), these match the pg_hba.conf lines that start with `host` and encompass one or the other of those networks. note that even if your system isn't using ipv6 for its network connections, it very well could be using the ipv6 localhost ::1 (shorthand for 0000:0000:0000:0000:0000:0000:0000:0001)... -- john r pierce, recycling bits in santa cruz
On Wed, 28 Dec 2016, John R Pierce wrote: > with psql, no -h and -h localhost are two different connection types. if > you don't specify a -h, it uses a 'unix domain socket', Thanks, John. I believe that I understand the differences. Here, /var/lib/pgsql/9.6/data/pg_hba.conf contains: # IPv4 local connections: host all rshepard 192.168.55.0/24 trust hostnossl all rshepard 192.168.55.0/24 trust I've left the ipv6 line alone. Regards, Rich
On Wed, 28 Dec 2016, John R Pierce wrote: > with psql, no -h and -h localhost are two different connection types. if > you don't specify a -h, it uses a 'unix domain socket', Thanks, John. I believe that I understand the differences. Here, /var/lib/pgsql/9.6/data/pg_hba.conf contains: # IPv4 local connections: host all rshepard 192.168.55.0/24 trust hostnossl all rshepard 192.168.55.0/24 trust I've left the ipv6 line alone. Regards, Rich
On 12/28/2016 11:55 AM, Rich Shepard wrote:
On Wed, 28 Dec 2016, John R Pierce wrote:with psql, no -h and -h localhost are two different connection types. if
you don't specify a -h, it uses a 'unix domain socket',
Thanks, John. I believe that I understand the differences. Here,
/var/lib/pgsql/9.6/data/pg_hba.conf contains:
# IPv4 local connections:
host all rshepard 192.168.55.0/24 trust
hostnossl all rshepard 192.168.55.0/24 trust
I would never 'trust' a whole LAN subnet, I generally use md5 password authentication over a LAN. if these java processes are running on the same host as the database server, you probably want to allow connections from localhost (127.0.0.1 and ::1), frankly, I usually don't even like to use 'trust' on localhost.
-- john r pierce, recycling bits in santa cruz
On 12/28/2016 11:55 AM, Rich Shepard wrote:
On Wed, 28 Dec 2016, John R Pierce wrote:with psql, no -h and -h localhost are two different connection types. if
you don't specify a -h, it uses a 'unix domain socket',
Thanks, John. I believe that I understand the differences. Here,
/var/lib/pgsql/9.6/data/pg_hba.conf contains:
# IPv4 local connections:
host all rshepard 192.168.55.0/24 trust
hostnossl all rshepard 192.168.55.0/24 trust
I would never 'trust' a whole LAN subnet, I generally use md5 password authentication over a LAN. if these java processes are running on the same host as the database server, you probably want to allow connections from localhost (127.0.0.1 and ::1), frankly, I usually don't even like to use 'trust' on localhost.
-- john r pierce, recycling bits in santa cruz
Hello, On Wed, 2016-12-28 at 07:45 -0800, Rich Shepard wrote: > PostgreSQL-9.6.1 and openjdk-8u91_b14 are installed on my > Slackware-14.1 > system and I am trying to use schemaSpy_5.0.0.jar on a couple of > databases. > I have downloaded postgresql-9.4.1212.jre6.jar but cannot get > schemaSpy to > run. > > 1) Is the -9.4.1212 version of the driver compatible with > postgres-9.6.1? > If not, is there a working alternative? > > 2) My databases are used by only me. All non-postgres-installed > databases > are owned by me so neither a username nor a password is required for > me to > access them. My login name is used by psql to allow me access. Is the > lack > of a password preventing the driver from functioning? If so, is there > a way > to inform it that no password is required here? > > TIA, > > Rich > > > Your application schemaSpy has to compose an URL (and optionally some properties may be set) that is compatible with postgresql.conf and pg_hba.conf. The usual URL is "IP Address:port number/database name". So the IP address is the same as what you have in pg_hba.conf and the port number as specified in the postgresql.conf being used by the relevant postmaster process. If you want to run different versions of Postgres they need to use unique port numbers for each version. HTH, Rob
Hello, On Wed, 2016-12-28 at 07:45 -0800, Rich Shepard wrote: > PostgreSQL-9.6.1 and openjdk-8u91_b14 are installed on my > Slackware-14.1 > system and I am trying to use schemaSpy_5.0.0.jar on a couple of > databases. > I have downloaded postgresql-9.4.1212.jre6.jar but cannot get > schemaSpy to > run. > > 1) Is the -9.4.1212 version of the driver compatible with > postgres-9.6.1? > If not, is there a working alternative? > > 2) My databases are used by only me. All non-postgres-installed > databases > are owned by me so neither a username nor a password is required for > me to > access them. My login name is used by psql to allow me access. Is the > lack > of a password preventing the driver from functioning? If so, is there > a way > to inform it that no password is required here? > > TIA, > > Rich > > > Your application schemaSpy has to compose an URL (and optionally some properties may be set) that is compatible with postgresql.conf and pg_hba.conf. The usual URL is "IP Address:port number/database name". So the IP address is the same as what you have in pg_hba.conf and the port number as specified in the postgresql.conf being used by the relevant postmaster process. If you want to run different versions of Postgres they need to use unique port numbers for each version. HTH, Rob
On Wed, 28 Dec 2016, Rich Shepard wrote: > 2) My databases are used by only me. All non-postgres-installed databases > are owned by me so neither a username nor a password is required for me to > access them. I want to thank all of you who responded to this pair of questions. I have installed the postgresql-jdbc driver and found a tool -- F/OSS -- that does exactly what I need: dbeaver <http://www.dbeaver.com/>. After spending most of two days trying to get schemaSpy and pgmodeler to work, I took a careful look at an older version of dbeaver I discovered here, upgraded it, and got it working in just a few minutes without detailed docs. Since my business is not that of a computer professional (coder, DBA, SysAdmin, etc.) good enough is sufficient for the tools I use. May you all have a healthy, prosperous, and satisfying 2017, Rich
On Wed, 28 Dec 2016, Rich Shepard wrote: > 2) My databases are used by only me. All non-postgres-installed databases > are owned by me so neither a username nor a password is required for me to > access them. I want to thank all of you who responded to this pair of questions. I have installed the postgresql-jdbc driver and found a tool -- F/OSS -- that does exactly what I need: dbeaver <http://www.dbeaver.com/>. After spending most of two days trying to get schemaSpy and pgmodeler to work, I took a careful look at an older version of dbeaver I discovered here, upgraded it, and got it working in just a few minutes without detailed docs. Since my business is not that of a computer professional (coder, DBA, SysAdmin, etc.) good enough is sufficient for the tools I use. May you all have a healthy, prosperous, and satisfying 2017, Rich