I'm not sure what else we would call it? All the other vendors call their products JDBC drivers so I don't see why we can't
1 - Yes, I actually specifically used SquirrelSQL for debugging during development because it was also open source and I could attach the debugger to SquirrelSQL and see what was going on when things didn't work. I've also successfully used the driver with some other JDBC tools. 2 - Probably not, since those framework typically generate SQL and SQL is explicitly not supported 2/3 - No, it is a type 4 driver in that it is pure Java but it is not JDBC compliant because by definition that requires supporting SQL. I have clarified the main page of the documentation to state this. The documentation is quite clear that this is a SPARQL over JDBC driver so I don't see that there is much room for confusion providing users RTFM. Rob On 8/24/13 3:50 AM, "Claude Warren" <[email protected]> wrote: >I am concerned about the name. Jena JDBC implies a level of >interoperability with existing JDBC based tools. I also note that JDBC >is >a trademark which I believe is owned by Oracle. > >But I have a few questions: > > > 1. Am I able to use the Jena JDBC driver to access a Jena based triple > store using a standard JDBC tool like SquirlSQL? > 2. Am I able to use the Jena JDBC driver within a JPA framework like > Hibernate? > 3. Does it pass the JDBC test suite (mentioned here: > http://docs.oracle.com/javase/tutorial/jdbc/overview/index.html) or at > least a major subset of the tests? I have not yet located the test >suite > itself. > >If the answer is no to any of these questions I wonder if the name is not >going to confuse potential users. > >Claude > > > >On Fri, Aug 23, 2013 at 11:16 PM, Stephen Allen <[email protected]> wrote: > >> Hi Rob, >> >> Looks pretty good. A few comments: >> >> a) Typo in second code block in section "Basic Usage | Making a >> Connection": s/"jdbc:jena:men:empty=true"/"jdbc:jena:mem:empty=true". >> Same error on drivers.html in the second code block of the >> "Available Drivers | In-Memory" section. >> >> b) Would suggest changing the section titles under Basic Usage to >> instead read: "Establishing a Connection", "Performing Queries", and >> "Performing Updates". >> >> c) Suggest adding try/finally blocks for both the Query and Update >> examples. >> >> d) Suggest adding an example of transactions for TDB connections >> (one that contains both read/update queries would be cool). >> >> >> -Stephen >> >> >> On Fri, Aug 23, 2013 at 5:58 PM, Rob Vesse <[email protected]> wrote: >> > I've put together some basic documentation which is in staging at >> > http://jena.staging.apache.org/documentation/jdbc/index.html if anyone >> > wants to review >> > >> > Rob >> > >> > >> > On 8/23/13 11:26 AM, "Rob Vesse" <[email protected]> wrote: >> > >> >>On the JDBC front I think it is essentially ready to go in this >>release, >> >>my main concern is integrating it into the build. >> >> >> >>Right now it is not called out as a module of the top level POM so >>does >> >>not automatically get built by mvn unless you go and build in the >> >>jena-jdbc directory yourself. >> >> >> >>However it is a slow build at ~5 mins or a modern machine like my 2011 >> >>MacBook Pro, and much longer on older/heavily contended machines like >> >>Apache build servers. Therefore my concern is whether developers are >> >>willing to stomach a longer build on their local machines? >> >> >> >>One thought I had was about using maven profiles, right now I have the >> >>following in my local uncommitted top level POM: >> >> >> >><profiles> >> >><profile> >> >><!-- >> >>This is the dev profile, it only builds the common modules and >> >>does not build the slow building JDBC modules or the distribution >> packages >> >>--> >> >><id>dev</id> >> >><activation> >> >><activeByDefault>true</activeByDefault> >> >></activation> >> >><modules> >> >><module>jena-parent</module> >> >><module>jena-iri</module> >> >><module>jena-core</module> >> >><module>jena-arq</module> >> >><module>jena-tdb</module> >> >><module>jena-text</module> >> >><module>jena-sdb</module> >> >><module>jena-fuseki</module> >> >><!-- Slow to build - exclude from default dev build --> >> >><!-- <module>jena-jdbc</module>--> >> >><module>apache-jena-libs</module> >> >><!-- Don't build distro package every time --> >> >><!-- <module>apache-jena</module> --> >> >></modules> >> >></profile> >> >><profile> >> >><!-- >> >>This is the complete profile, it builds everything including slow >> >>building modules and >> >>the distribution packages. >> >>This profile should be enabled when cutting a release >> >>-P apache-release,complete >> >>--> >> >><id>complete</id> >> >><modules> >> >><module>jena-parent</module> >> >><module>jena-iri</module> >> >><module>jena-core</module> >> >><module>jena-arq</module> >> >><module>jena-tdb</module> >> >><module>jena-text</module> >> >><module>jena-sdb</module> >> >><module>jena-fuseki</module> >> >><module>jena-jdbc</module> >> >><module>apache-jena-libs</module> >> >><module>apache-jena</module> >> >></modules> >> >></profile> >> >></profiles> >> >> >> >>Would people be OK with going with something like this? It would mean >> >>that by default we only build the common modules and then when we >>come to >> >>do releases or want a more thorough build we can build the complete >>thing >> >>(or even add a third release specific profile?). We may want to have >>a >> >>little more discussion about which modules go in which profile and how >> >>many profiles we want to have. I can commit what I have now and >>people >> >>can iterate on it? >> >> >> >>Getting back to JDBC specifics, no there is not any website >>documentation >> >>yet. However the javadoc is pretty comprehensive so with a couple of >> >>basic web pages written up may be sufficient, I will try and at least >> >>stub those pages out today. >> >> >> >>Rob >> > >> > > > >-- >I like: Like Like - The likeliest place on the >web<http://like-like.xenei.com> >Identity: https://www.identify.nu/[email protected] >LinkedIn: http://www.linkedin.com/in/claudewarren
