bruceyue / force-metadata-jdbc-driver

Automatically exported from code.google.com/p/force-metadata-jdbc-driver
0 stars 0 forks source link

Driver is not as compliant with JDBC spec as it could be #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I tried to use the driver with http://ermodeller.tigris.org/  however, it would 
not connect and just printed, "No suitable driver found".  According to section 
9.3 of the JDBC Spec: http://java.cnam.fr/iagl/biblio/spec/jdbc-3_0-fr-spec.pdf

1. The driver should register itself with the driver manager via static 
initialization.  I added this code to ForceMetaDataDriver.java:

    static {
        try {
            DriverManager.registerDriver(new ForceMetaDataDriver());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

2. Some applications use the DataSource API, which expect the driver to 
recognize the standard properties "user" and "password".  I added code for the 
driver to work with these properties, while still maintaining backward 
compatibility with "jdbc:claimvantage:force:someuser:somepassword" way of 
configuring user/password.

The source code is here:

http://chriswolf.heroku.com/page_attachments/0000/0022/force-metadata-jdbc-drive
r-1.4.cw-sources.jar

Original issue reported on code.google.com by cw10...@gmail.com on 31 Jan 2011 at 4:20

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by keith.clarke.claimvantage@gmail.com on 14 Feb 2011 at 2:56

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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