You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2008/12/09 12:46:22 UTC
JDBC to JCR
Hi,
I'm planning to do some experiments with the Derby "saucer separation"
mechanism (see [1]) as a way to implement a JDBC driver for accessing
JCR content repositories. :-)
Let's see how it turns out... I'll be setting up a jdbc2jcr component
in the sandbox for any prototype code I come up with.
[1] http://people.apache.org/~rhillegas/vtiDemo/doc/saucerSeparation.html
BR,
Jukka Zitting
Re: JDBC to JCR
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Dec 9, 2008 at 1:49 PM, Thomas Müller <th...@day.com> wrote:
> Did you have a look at the JDBC to JCR bridge:
> http://wiki.apache.org/jackrabbit/QueryUsingJdbc
Yes, I saw that. I'm looking for a more generic alternative, one that
exposes all available node types (or other criteria for selecting
nodes) as virtual tables and allows you to perform arbitrary joins
across those tables.
BR,
Jukka Zitting
Re: JDBC to JCR
Posted by Thomas Müller <th...@day.com>.
Hi,
Did you have a look at the JDBC to JCR bridge:
http://wiki.apache.org/jackrabbit/QueryUsingJdbc
Regards,
Thomas
On Tue, Dec 9, 2008 at 1:46 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Tue, Dec 9, 2008 at 12:52 PM, Alexander Klimetschek <ak...@day.com> wrote:
>> Interesting ;-) Is the way using these virtual function tables simpler
>> than directly implementing the JDBC API? I think the JDBC API is not
>> so difficult....
>
> The benefit of using Derby "saucer separation" is that Derby will do
> all the query execution based on the table data you return. You'll
> actually have JOINs, GROUP BYs, subselects, and all kinds of other
> nice features that JCR lacks. Of course it'll be dog-slow, but it
> opens up a whole new range of functionality and lots of integration
> options.
>
> BR,
>
> Jukka Zitting
>
Re: JDBC to JCR
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Dec 9, 2008 at 12:52 PM, Alexander Klimetschek <ak...@day.com> wrote:
> Interesting ;-) Is the way using these virtual function tables simpler
> than directly implementing the JDBC API? I think the JDBC API is not
> so difficult....
The benefit of using Derby "saucer separation" is that Derby will do
all the query execution based on the table data you return. You'll
actually have JOINs, GROUP BYs, subselects, and all kinds of other
nice features that JCR lacks. Of course it'll be dog-slow, but it
opens up a whole new range of functionality and lots of integration
options.
BR,
Jukka Zitting
Re: JDBC to JCR
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Dec 9, 2008 at 12:46 PM, Jukka Zitting <ju...@gmail.com> wrote:
> I'm planning to do some experiments with the Derby "saucer separation"
> mechanism (see [1]) as a way to implement a JDBC driver for accessing
> JCR content repositories. :-)
Interesting ;-) Is the way using these virtual function tables simpler
than directly implementing the JDBC API? I think the JDBC API is not
so difficult....
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com