Closed GoogleCodeExporter closed 9 years ago
Thanks Chris. Bit tied up right now but I'll add these changes soon.
Original comment by keith.clarke.claimvantage@gmail.com
on 31 Jan 2011 at 4:31
I just uploaded those jars again. I made A LOT of changes to implement more of
the
metadata API so that I could use the driver with another ERD tool called Open
Model Sphere.
http://chriswolf.heroku.com/articles/2011/01/30/generating-salesforce-entity-rel
ationship-diagrams/
I know it's not much for SchemaSpy because it already worked for that, but now
it works
for Model Sphere (which it was not even close to working without the changes).
I think the
value-add is that it has a much better chance of working with other ER tools.
I'm pretty much done for now. Let me know if you plan to merge the changes, or
if you
prefer that I fork off a different project (of course, giving you most of the
credit).
-Chris
Original comment by cw10...@gmail.com
on 1 Feb 2011 at 6:19
Chris, trying your jars works well in a production org, but I cannot get it to
work on a Sandbox. I tried the connprops method and also tried changing
connectionSpec with no luck. Using the connprops method if I put in a partial
url like https://test.salesforce.com it would error saying the endpoint was not
specified correctly. If I then put in
https://test.salesforce.com/services/Soap/u/20.0 it would run, but connect to
production. Any ideas?
Thanks,
Paul
Original comment by paul.bla...@configero.com
on 10 Feb 2011 at 6:10
Let me look into it. It will take a few days, though.
Original comment by cw10...@gmail.com
on 10 Feb 2011 at 6:33
I found a possible issue with how the authentication URL is overriden. I don't
have access to a sandbox (I only have a developer account). Can you test again
with the attached JAR?
Original comment by cw10...@gmail.com
on 12 Feb 2011 at 8:03
Attachments:
Chris,
Back on the subject of merging, its a bit of a pain for you and me, but for
other users a single version of the driver that gets better over time makes
sense.
I took a look at your code changes and found these three pretty independent
sets of changes:
1) More complete implementation of the interfaces, particularly in
ResultSetFactory.
2) Modifications to compile against the 1.6 versions of the java.sql.* classes.
3) Changes (all in Service) to move away from Axis.
I suggest for this project it is best to change these separately rather than
together. If I merge your (1) changes I can test that the SchemaSpy outputs of
my build are not affected; would you be willing to check the result against
your Open ModelSphere setup? Then when we are both happy I can post that as a
version 1.5 of the driver (credited to you).
We can then have further debate about item (3).
Keith
Original comment by keith.clarke.claimvantage@gmail.com
on 13 Feb 2011 at 1:49
Ok, setting aside #3 for now - yes I can test post-merge with ModelSphere.
Just to clarify #2 - I undid the JDBC-4 (jdk-1.6) changes because Open
ModelSphere needs jdk-1.5 (JDBC-3 API), so I built partner.jar and wsc.jar and
the force-metadata-driver.jar with JDK-1.5 (not 1.6) Those extra methods were
no-ops anyway.
Original comment by cw10...@gmail.com
on 13 Feb 2011 at 11:49
Chris,
force-metadata-jdbc-driver-1.4.1.cw.jar successfully connected to the Sandbox
and pulled the correct data. Thanks for the quick fix!
I used -connprops
custom\=true;standard\=false;url\=https://test.salesforce.com/services/Soap/u/20
.0
When I used -connprops
custom\=true;standard\=false;url\=https://test.salesforce.com/services/Soap/u/18
.0
I received the following error which I suspect is because the partner jar is
version 20.
[java] Failed to connect to database URL [jdbc:claimvantage:force]
[java]
[java] java.sql.SQLException: com.sforce.ws.ConnectionException: Unexpected
element. Parser was expecting element 'urn:partner.soap.sforce.com:feedEnabled'
but found 'urn:partner.soap.sforce.com:keyPrefix'
[java] at com.sforce.ws.bind.TypeMapper.verifyTag(TypeMapper.java:386)
.....
Original comment by paul.bla...@configero.com
on 14 Feb 2011 at 1:59
Chris,
I've merged your changes and tested them with SchemaSpy and that seems ok.
There is a jar of the modified code in the downloads presently called
force-metadata-jdbc-driver-1.5-beta.jar and I've committed the source too.
If you can check that this works with Open ModelSphere (and Ideally review the
source code too) that would be great. If it doesn't please supply any fixes
needed.
Do you want me to link to a page of your site for a "How to use with Open
ModelSphere" article or do we need to find a way for you to author a wiki page
here?
Keith
Original comment by keith.clarke.claimvantage@gmail.com
on 14 Feb 2011 at 2:55
Original comment by keith.clarke.claimvantage@gmail.com
on 14 Feb 2011 at 2:56
Keith,
I tested your 1.5-beta with Open ModelSphere and it worked. I also reviewed
the code and I concur with the minor changes you made, i.e. allcaps for type
info table, and replace Vector with ArrayList. Except it appears you omitted
my code change in ForceMetaDataDriver.java which allows the user/password to be
specified in the URL as properties per the JDBC spec.
BTW, the patches I supplied were not just for "ModelSphere support", as the
download page caption says, but rather implementing more of the missing JDBC
implementation which happens to make it work for ModelSphere - i.e. it's not
*just* a ModelSphere support change. It's likely the change may make the driver
usable with other db ERD tools as well.
Thanks,
-Chris
Original comment by cw10...@gmail.com
on 16 Feb 2011 at 11:00
Chris,
Thanks for trying this out.
I believe I included all your work. I moved the code that obtains the
user/password to a separate class so that I could create test cases for the
various options as there are now quite a few including combinations. Let me
know if I missed an option - see the test case
http://code.google.com/p/force-metadata-jdbc-driver/source/browse/trunk/force-me
tadata-jdbc-driver/src/com/claimvantage/force/jdbc/CredentialsTest.java.
I've changed the project summary page to reflect your comment.
Keith
Original comment by keith.clarke.claimvantage@gmail.com
on 16 Feb 2011 at 11:19
Oh, when I reviewed the code I looked at the source in the beta jar - not svn,
because
when I did an "svn diff" on a few files, it didn't look like the patches were
in source
control.
I'll have another look.
Original comment by cw10...@gmail.com
on 16 Feb 2011 at 11:26
Original issue reported on code.google.com by
cw10...@gmail.com
on 31 Jan 2011 at 4:20