Thread: Visualization of structure (OT?)
Hi all! This might be off topic, my apoligies if my question's misdirected. I'm looking for a way to visualize tha tables within a given database, pretty much the way BlueJ (www.bluej.org - doesn't play well with JDK1.4) shows sub- and superclass relationships. Have anyone seen anything like this (freeware that is - numerous propietary solutions exist for MS SQL etc.)? Most preferably I'd like to parse CREATE clauses, to be able to parse/extract external keys and display that correctly. I guess I will have to do it myself - and I probably will since I'm fed up using xfig (vector based graphical tool). Nothing wrong with xfig, but it's not designed to be used for this. As far as I've understood - all information that's needed to make a complete graph/schema of the relations can't be extracted with the jdbc-driver provided from jdbc.postgresql.org. Is this true? Thanks in advance, Fredrik PS. On-screen visualization is the primary target, PostScript generation comes second. DS
Fredrik As far as I know DbVisualier (www.minq.se) works with postgres as well as druid http://sourceforge.net/projects/druid/ If this isn't the case let me know, it was working last time I checked Dave > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Fredrik Wendt > Sent: Sunday, March 17, 2002 7:28 PM > To: pgsql-jdbc@postgresql.org > Subject: [JDBC] Visualization of structure (OT?) > > > Hi all! > > This might be off topic, my apoligies if my question's misdirected. > > I'm looking for a way to visualize tha tables within a given > database, pretty much the way BlueJ (www.bluej.org - doesn't > play well with > JDK1.4) shows sub- and superclass relationships. Have anyone > seen anything like this (freeware that is - numerous > propietary solutions exist for MS SQL etc.)? Most preferably > I'd like to parse CREATE clauses, to be able to parse/extract > external keys and display that correctly. I guess I will have > to do it myself - and I probably will since I'm fed up using > xfig (vector based graphical tool). Nothing wrong with xfig, > but it's not designed to be used for this. > As far as I've understood - all information that's > needed to make a complete graph/schema of the relations can't > be extracted with the jdbc-driver provided from > jdbc.postgresql.org. Is this true? > > Thanks in advance, > > Fredrik > > PS. On-screen visualization is the primary target, PostScript > generation > comes second. DS > > > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > >
Fredik Here is some code which uses cursors Dave public void testCursor() { Connection con = null; try { con = getConnection(); // cursors work inside a transaction con.setAutoCommit(false); Statement stmt = con.createStatement(); // sufficiently long select as to get us something we can scroll through stmt.execute("declare cursorname cursor for select * from pg_class"); ResultSet rs = stmt.executeQuery("fetch 10 from cursorname"); while (rs.next()){ System.out.println(rs.getString(1)); } rs.close(); // close the cursor con.commit(); } catch (Exception ex) { ex.printStackTrace(); } finally { try { if ( con != null ) con.close(); }catch ( SQLException ex ) {} } }
For my information; this means I probably need a new connection object for each cursor due to the fact that it is within a transaction and those are serial in nature by default on a connection even though this is a pure select statement. This begs the question of how expensive is a new connection. Is it a new thread or process on the backend? I think the answer is process. Again FMI, why is a cursor necessarily within a transaction? Also I think any connection object is serialized at the backend anyway true/false? TIA for any responses. BTW, this is not a complaint by me as most modern UNIX'es are reasonably efficient at process creation and destruction especially when the initial data and stack segments are reasonable in size since the Text segment is irrelevant. Might be more of a problem for other OS'es. At 10:48 PM 3/17/2002 -0500, Dave Cramer wrote: >Fredik > >Here is some code which uses cursors > >Dave > > public void testCursor() > { > Connection con = null; > try { > con = getConnection(); > > // cursors work inside a transaction > con.setAutoCommit(false); > > Statement stmt = con.createStatement(); > > // sufficiently long select as to get us something we can scroll >through > stmt.execute("declare cursorname cursor for select * from >pg_class"); > > ResultSet rs = stmt.executeQuery("fetch 10 from cursorname"); > > while (rs.next()){ > System.out.println(rs.getString(1)); > } > rs.close(); > > // close the cursor > con.commit(); > > } > catch (Exception ex) > { > ex.printStackTrace(); > } > finally > { > try { > if ( con != null ) > con.close(); > }catch ( SQLException ex ) {} > } > > } > > > >---------------------------(end of broadcast)--------------------------- >TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Peter, I use a connection pool to deal with startup penalties, which I think are significant. It is a process on the backend. Not sure what you mean by serialized on the backend? Dave > -----Original Message----- > From: Peter V Cooper [mailto:pvcooper@adelphia.net] > Sent: Monday, March 18, 2002 10:52 AM > To: Dave@micro-automation.net; 'Fredrik Wendt'; > pgsql-jdbc@postgresql.org > Subject: Re: [JDBC] Scrolling through cursors > > > For my information; this means I probably need a > new connection object for each cursor due to the fact > that it is within a transaction and those are serial in > nature by default on a connection even though this > is a pure select statement. This begs the question > of how expensive is a new connection. Is it a new > thread or process on the backend? I think the answer > is process. Again FMI, why is a cursor necessarily > within a transaction? Also I think any connection > object is serialized at the backend anyway true/false? > > TIA for any responses. > > BTW, this is not a complaint by me as most modern UNIX'es > are reasonably efficient at process creation and destruction > especially when the initial data and stack segments are > reasonable in size since the Text segment is irrelevant. > Might be more of a problem for other OS'es. > > At 10:48 PM 3/17/2002 -0500, Dave Cramer wrote: > >Fredik > > > >Here is some code which uses cursors > > > >Dave > > > > public void testCursor() > > { > > Connection con = null; > > try { > > con = getConnection(); > > > > // cursors work inside a transaction > > con.setAutoCommit(false); > > > > Statement stmt = con.createStatement(); > > > > // sufficiently long select as to get us something we > can scroll > >through > > stmt.execute("declare cursorname cursor for select * from > >pg_class"); > > > > ResultSet rs = stmt.executeQuery("fetch 10 from cursorname"); > > > > while (rs.next()){ > > System.out.println(rs.getString(1)); > > } > > rs.close(); > > > > // close the cursor > > con.commit(); > > > > } > > catch (Exception ex) > > { > > ex.printStackTrace(); > > } > > finally > > { > > try { > > if ( con != null ) > > con.close(); > > }catch ( SQLException ex ) {} > > } > > > > } > > > > > > > >---------------------------(end of > >broadcast)--------------------------- > >TIP 1: subscribe and unsubscribe commands go to > majordomo@postgresql.org > >