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<h
ttp://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<ht
tp://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/user.**[email protected]<https://www.ident
ify.nu/[email protected]>
LinkedIn:
http://www.linkedin.com/in/**claudewarren<http://www.linkedin.com/in/
claudewarren>
