Oops, closed this one accidently during the bulk close stuff
and am re-opening it.
I didn't put the cross-schema stuff into release 3.0.0 due
to the possibility of breaking so many other areas. I'm
still thinking about how to do it cleanly.
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd love the proper evaluation of cross-schema FK as well. I
have a 200+ tables system which is split into several
modules. Generating the docu for individual modules requires
the cross-schema referencing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Count me in! Just put into svn or provide a patch against any svn revision, just name it. Well, patch against the source tarball would do if you want to. I'm more than willing to try it out (with postgres).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry I mistakenly stated that it isn't in svn, it seems to be in, but it doesn't work, yet, because it doesn't pass -host and -db to executed process in MultipleSchemaAnalyzer.analyze. Moreover, it choked on cmd.toArray(new String[]{}) trying to deal with Pattern list members:
Exception in thread "main" java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at java.util.ArrayList.toArray(ArrayList.java:304)
at net.sourceforge.schemaspy.MultipleSchemaAnalyzer.analyze(MultipleSchemaAnalyzer.java:55)
at net.sourceforge.schemaspy.SchemaAnalyzer.analyze(SchemaAnalyzer.java:69)
at net.sourceforge.schemaspy.Main.main(Main.java:11)
When I fixed the problem I bumped into not passing db-specific options and I haven't digged deeper since it looks like you're in the middle of some major changes related to it.
Just to let you know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I'm in the middle of a significant refactoring trying to get everything out of main and moving the configuration stuff somewhere appropriate so tools like Maven2 will work.
Note that I haven't started to tackle the fully-implemented -all option yet.
You've definitely found a bug in what I've done though. I wish that I could switch to Java 1.5 to avoid these types of collection mis-matches. I still haven't worked out -all and the refactoring that I'm doing...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
John, I'm not sure if it's a proper place for this discussion, let me know where to move to, if it's not: email, forum are okay with me.
I know you're doing this refactoring - I've read svn commit messages :)
It's strange that you claim you didn't switch to 1.5, because, basically, I switched because 1.4 failed to compile at Integer.valueOf() function. Note that I am not a Java expert (moreover, I have nearly no clue about java, but knowing heck of a lot of other languages helps), so I don't know whether it should've failed or not. But it did, so I switched to 1.5. I can switch back and forth with no problem, though, so if I can be of help - let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the last svn revision where it did pass -host -db down to spawned processed it did spit out the message ( I think it was r275, but not 100% sure). As for the latest trunk (r279 at the moment):
...
Analyzing X
*** Parameter 'db' (database name (from TNSNAMES.ORA)) missing. It is required for this database type. ***
SchemaSpy generates an HTML representation of a database schema's relationships.
Built-in database types and their required connection parameters:
db2:
null
-db database name
And after the '-db' line above it just sits there until I hit ^C. I'm using vi/command line, so I didn't bother trace insides and see where and why it sits, but it should pass the db specific option, anyway.
The command line was
java -jar dist/schemaSpy.jar -cp /usr/share/jdbc3-postgresql-1/lib/pg73jdbc3.jar -t pgsql -host localhost -db X -all -u X -p X -o X
(not exactly X, but who cares)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't figured out why -db (or -t evidently) isn't being passed through yet. It looks like your shell might be doing something with quoted params, so I've slightly changed that logic. Try rev 280. It *might* work better, but it prints out the arguments that create the child java process. We should be able to figure out what's going wrong from those.
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This time you're overdoing a bit. exec doesn't use shell, it uses exec. That's one part of a problem. The other is that it turns out that 1.4 (to which I occasionally switched) doesn't handle .toString() on patterns the way 1.5 does. To save on describing the problem I'm pasting the diff below.
And now to the issue - It does "Couldn't add FK ..." thing and again I didn't look into it (maybe "yet", but most likely I won't anytime soon, where "soon" is in a week or so).
Ah, I thought that I was running with 1.4, but I screwed up my paths and was still running 1.5.
I'm confused, however, about your MultipleSchemaAnalyzer changes. If I don't surround the params with quotes then the regular expressions with wildcards get expanded to the filenames in the current directory that they match. I take it that it didn't work the way it was or you wouldn't have changed it....
Thanks for helping to test this stuff out. These things that we're working through are all remnants of the refactoring to make SchemaSpy work with Maven2 and tools like it. I have some ideas on how to tackle *this* feature request, but I wanted to get the bugs worked out of the refactoring first. Note that it's been much more difficult than I had initially thought, mostly a result of the dynamic nature of the configuration stuff. That is, I don't know at design/coding time what parameters are going to be required...a big chunk of it is dynamically configured based on property files.
Thanks again,
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem, I can check with both VMs once in a while ;-)
No, regular expressions will not be expanded because exec executes exactly what you pass to it, it does not execute shell (which does the expansion) and then java. So what you get when you quoting parameters is effectively what you would get if you escape quotes (as in \"param\") in command line.
To be true, I doubt if re-executing SchemaSpy is a proper approach here... And yes, I understand where these troubles come from and that it doesn't have to do much with this feature request directly, I'm just trying to be helpful and originally I happened to be interested in this feature ;-)
And you're welcome, let me know if I can be of more help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not saying that it might expand but rather that it does expand, at least on WinXP. That's why I had to quote the parameters. Hopefully what's in svn now will work for any OS.
I might eventually have to use an alternate method of getting the params to the secondary SchemaSpy. The idea of not re-executing SchemaSpy would be extremely painful with significant risks.
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad that part of it works now. Now I've got to brush up on J2EE for my resume as the government will most likely drop funding for the project that I'm working on. Hopefully I'll have some time to work on the cross-schema stuff.
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Michael, can you give rev 299 a try? Note that I don't have anything to test this on...
The "other schema" tables should show up in the various graphs now. One side effect is that -all will take a little longer to execute as I now have to get every table's "exported keys" in addition to "imported keys". If I didn't then you wouldn't know about "other schema" tables that reference PK's in this schema.
Let me know how it works (or more likely where it blows up ;)
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1264584
Link to the original discussion:
http://sourceforge.net/forum/forum.php?thread_id=1455292&forum_id=462850
Logged In: YES
user_id=1264584
It's in release 3.0.0.
Logged In: YES
user_id=1264584
Oops, closed this one accidently during the bulk close stuff
and am re-opening it.
I didn't put the cross-schema stuff into release 3.0.0 due
to the possibility of breaking so many other areas. I'm
still thinking about how to do it cleanly.
John
Logged In: YES
user_id=157525
I'd love the proper evaluation of cross-schema FK as well. I
have a 200+ tables system which is split into several
modules. Generating the docu for individual modules requires
the cross-schema referencing.
Logged In: YES
user_id=578710
Originator: NO
It isn't in the latest release and isn't in subversion either yet?
Nice tool (thanks), but wants this feature badly ;-)
Just to let you know there are more people who want it.
Logged In: YES
user_id=1264584
Originator: NO
It's definitely on the list for the next release. And I'll need beta testers ;)
Logged In: YES
user_id=578710
Originator: NO
Count me in! Just put into svn or provide a patch against any svn revision, just name it. Well, patch against the source tarball would do if you want to. I'm more than willing to try it out (with postgres).
Logged In: YES
user_id=578710
Originator: NO
I'm sorry I mistakenly stated that it isn't in svn, it seems to be in, but it doesn't work, yet, because it doesn't pass -host and -db to executed process in MultipleSchemaAnalyzer.analyze. Moreover, it choked on cmd.toArray(new String[]{}) trying to deal with Pattern list members:
Exception in thread "main" java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at java.util.ArrayList.toArray(ArrayList.java:304)
at net.sourceforge.schemaspy.MultipleSchemaAnalyzer.analyze(MultipleSchemaAnalyzer.java:55)
at net.sourceforge.schemaspy.SchemaAnalyzer.analyze(SchemaAnalyzer.java:69)
at net.sourceforge.schemaspy.Main.main(Main.java:11)
When I fixed the problem I bumped into not passing db-specific options and I haven't digged deeper since it looks like you're in the middle of some major changes related to it.
Just to let you know.
Logged In: YES
user_id=1264584
Originator: NO
Yes, I'm in the middle of a significant refactoring trying to get everything out of main and moving the configuration stuff somewhere appropriate so tools like Maven2 will work.
Note that I haven't started to tackle the fully-implemented -all option yet.
You've definitely found a bug in what I've done though. I wish that I could switch to Java 1.5 to avoid these types of collection mis-matches. I still haven't worked out -all and the refactoring that I'm doing...
Logged In: YES
user_id=578710
Originator: NO
John, I'm not sure if it's a proper place for this discussion, let me know where to move to, if it's not: email, forum are okay with me.
I know you're doing this refactoring - I've read svn commit messages :)
It's strange that you claim you didn't switch to 1.5, because, basically, I switched because 1.4 failed to compile at Integer.valueOf() function. Note that I am not a Java expert (moreover, I have nearly no clue about java, but knowing heck of a lot of other languages helps), so I don't know whether it should've failed or not. But it did, so I switched to 1.5. I can switch back and forth with no problem, though, so if I can be of help - let me know.
Logged In: YES
user_id=1264584
Originator: NO
Ah, nice catch. My Eclipse is running 1.5 but the project is configured for 1.4 only. It looks like I'll have to be extremely careful.
Thanks!
John
Logged In: YES
user_id=1264584
Originator: NO
Michael, when you run with -all do you get "Couldn't add FK" error messages? Just trying to figure out where this fits in.
John
Logged In: YES
user_id=578710
Originator: NO
In the last svn revision where it did pass -host -db down to spawned processed it did spit out the message ( I think it was r275, but not 100% sure). As for the latest trunk (r279 at the moment):
...
Analyzing X
*** Parameter 'db' (database name (from TNSNAMES.ORA)) missing. It is required for this database type. ***
SchemaSpy generates an HTML representation of a database schema's relationships.
Built-in database types and their required connection parameters:
db2:
null
-db database name
And after the '-db' line above it just sits there until I hit ^C. I'm using vi/command line, so I didn't bother trace insides and see where and why it sits, but it should pass the db specific option, anyway.
The command line was
java -jar dist/schemaSpy.jar -cp /usr/share/jdbc3-postgresql-1/lib/pg73jdbc3.jar -t pgsql -host localhost -db X -all -u X -p X -o X
(not exactly X, but who cares)
Logged In: YES
user_id=1264584
Originator: NO
I haven't figured out why -db (or -t evidently) isn't being passed through yet. It looks like your shell might be doing something with quoted params, so I've slightly changed that logic. Try rev 280. It *might* work better, but it prints out the arguments that create the child java process. We should be able to figure out what's going wrong from those.
John
Logged In: YES
user_id=578710
Originator: NO
This time you're overdoing a bit. exec doesn't use shell, it uses exec. That's one part of a problem. The other is that it turns out that 1.4 (to which I occasionally switched) doesn't handle .toString() on patterns the way 1.5 does. To save on describing the problem I'm pasting the diff below.
And now to the issue - It does "Couldn't add FK ..." thing and again I didn't look into it (maybe "yet", but most likely I won't anytime soon, where "soon" is in a week or so).
Index: src/net/sourceforge/schemaspy/MultipleSchemaAnalyzer.java
--- src/net/sourceforge/schemaspy/MultipleSchemaAnalyzer.java (revision 280)
+++ src/net/sourceforge/schemaspy/MultipleSchemaAnalyzer.java (working copy)
@@ -35,11 +35,7 @@
}
for (Iterator iter = args.iterator(); iter.hasNext(); ) {
- String next = iter.next().toString();
- if (next.startsWith("-"))
- genericCommand.add(next);
- else
- genericCommand.add("\"" + next + "\"");
+ genericCommand.add(iter.next().toString());
}
System.out.println("Analyzing schemas that match regular expression '" + schemaSpec + "':");
Index: src/net/sourceforge/schemaspy/Config.java
===================================================================
--- src/net/sourceforge/schemaspy/Config.java (revision 280)
+++ src/net/sourceforge/schemaspy/Config.java (working copy)
@@ -767,9 +767,9 @@
list.add(value);
}
list.add("-i");
- list.add(getInclusions().toString());
+ list.add(getInclusions().pattern());
list.add("-x");
- list.add(getExclusions().toString());
+ list.add(getExclusions().pattern());
list.add("-dbthreads");
list.add(String.valueOf(getMaxDbThreads()));
list.add("-maxdet");
Logged In: YES
user_id=1264584
Originator: NO
Ah, I thought that I was running with 1.4, but I screwed up my paths and was still running 1.5.
I'm confused, however, about your MultipleSchemaAnalyzer changes. If I don't surround the params with quotes then the regular expressions with wildcards get expanded to the filenames in the current directory that they match. I take it that it didn't work the way it was or you wouldn't have changed it....
Thanks for helping to test this stuff out. These things that we're working through are all remnants of the refactoring to make SchemaSpy work with Maven2 and tools like it. I have some ideas on how to tackle *this* feature request, but I wanted to get the bugs worked out of the refactoring first. Note that it's been much more difficult than I had initially thought, mostly a result of the dynamic nature of the configuration stuff. That is, I don't know at design/coding time what parameters are going to be required...a big chunk of it is dynamically configured based on property files.
Thanks again,
John
Logged In: YES
user_id=578710
Originator: NO
No problem, I can check with both VMs once in a while ;-)
No, regular expressions will not be expanded because exec executes exactly what you pass to it, it does not execute shell (which does the expansion) and then java. So what you get when you quoting parameters is effectively what you would get if you escape quotes (as in \"param\") in command line.
To be true, I doubt if re-executing SchemaSpy is a proper approach here... And yes, I understand where these troubles come from and that it doesn't have to do much with this feature request directly, I'm just trying to be helpful and originally I happened to be interested in this feature ;-)
And you're welcome, let me know if I can be of more help.
Logged In: YES
user_id=1264584
Originator: NO
I'm not saying that it might expand but rather that it does expand, at least on WinXP. That's why I had to quote the parameters. Hopefully what's in svn now will work for any OS.
I might eventually have to use an alternate method of getting the params to the secondary SchemaSpy. The idea of not re-executing SchemaSpy would be extremely painful with significant risks.
John
Logged In: YES
user_id=578710
Originator: NO
Okay, now I remember. What is done by shell in unix is processed by runtime library in executable in DOS (and windows for that matter).
Well, you know your code better, I only speak from my experience and my perception of common sense.
The svn code seems to work now.
Logged In: YES
user_id=1264584
Originator: NO
Glad that part of it works now. Now I've got to brush up on J2EE for my resume as the government will most likely drop funding for the project that I'm working on. Hopefully I'll have some time to work on the cross-schema stuff.
John
Logged In: YES
user_id=1264584
Originator: NO
Michael, can you give rev 299 a try? Note that I don't have anything to test this on...
The "other schema" tables should show up in the various graphs now. One side effect is that -all will take a little longer to execute as I now have to get every table's "exported keys" in addition to "imported keys". If I didn't then you wouldn't know about "other schema" tables that reference PK's in this schema.
Let me know how it works (or more likely where it blows up ;)
John