Обсуждение: 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
>
>