jDBI for CRUD and Spring

830 views
Skip to first unread message

CemoKoc

unread,
Feb 19, 2012, 10:59:16 AM2/19/12
to jDBI
Hi,

Thanks to Brian I have seen this wonderful library. SqlObject Api is
wonderful. :)

Although Spring Data (JPA) has a similar paradigm as jDBI, I dislike
JPA and its entity manager based implementations. I am with Spring
JDBCTemplate and its simple usage with connection pools. What I would
like to learn is extending my daily workflow with jDBI is possible or
not.

1. Is there any CRUD Support like JPARepository [1]
2. Is there any way to integrate JDBI SqlObject Api with spring?
3. What is the overhead utilizing interface base approach over Fluent
API?

By the way, despite of disliking JPA, I believe that barrowing
necessary annotations from JPA is possible for generalizing for
necessary usage. I came across a few more libraries utilizing JPA for
their needs.

Thanks

[1].
http://static.springsource.org/spring-data/data-jpa/docs/1.0.2.RELEASE/api/org/springframework/data/jpa/repository/JpaRepository.html

Brian McCallister

unread,
Feb 21, 2012, 12:18:52 PM2/21/12
to jd...@googlegroups.com
On Sun, Feb 19, 2012 at 8:59 AM, CemoKoc <cemalet...@gmail.com> wrote:
> Hi,
>
> Thanks to Brian I have seen this wonderful library. SqlObject Api is
> wonderful. :)
>
> Although Spring Data (JPA) has a similar paradigm as jDBI, I dislike
> JPA and its entity manager based implementations. I am with Spring
> JDBCTemplate and its simple usage with connection pools. What I would
> like to learn is extending my daily workflow with jDBI is possible or
> not.
>
> 1. Is there any CRUD Support like JPARepository [1]

Nothing built in.

> 2. Is there any way to integrate JDBI SqlObject Api with spring?

Sure, the best way to do it depends on your circumstances. The easiest
path is probably a bean factory building on demand sql object
instances.

> 3. What is the overhead utilizing interface base approach over Fluent
> API?

Sure, there is some overhead from the invokevirtual going to a hash
based dispatch internally, but you shouldn't be able to reliably even
measure it given the network chatter out to the database. If you find
significant overhead then that is a bug which needs to be fixed.

At some point, when I get a good chunk of free time, I want to provide
for using CGLIB for sql object instantiation -- this should remove any
overhead fo the dynamic dispatch, and would allow for class based sql
object instances -- which opens some nice options for modeling
transactional stuff better.

> By the way, despite of disliking JPA, I believe that barrowing
> necessary annotations from JPA is possible for generalizing for
> necessary usage. I came across a few more libraries utilizing JPA for
> their needs.

It should be straightforward to use JPA annotations to do mapping in
and out of sql object method invocations, but that is something (like
expressions for binding) I have resisted putting into the core library
as it seems that if you want transparent ORM, you should probably use
a transparent ORM tool (JPA, etc). There is a wide range in between
"making sql convenient" and transparent ORM, but it feels to me like
the steps taking JDBI towards transparent ORM should be an additional
librray built on JDBI rather than part of JDBI.

-Brian

Tatu Saloranta

unread,
Feb 21, 2012, 1:26:18 PM2/21/12
to jd...@googlegroups.com
One random note here:

On Tue, Feb 21, 2012 at 9:18 AM, Brian McCallister <bri...@skife.org> wrote:
> On Sun, Feb 19, 2012 at 8:59 AM, CemoKoc <cemalet...@gmail.com> wrote:
>> Hi,
>>
>> Thanks to Brian I have seen this wonderful library. SqlObject Api is
>> wonderful. :)

...


> It should be straightforward to use JPA annotations to do mapping in
> and out of sql object method invocations, but that is something (like
> expressions for binding) I have resisted putting into the core library

....

I don't know if it'd be of any use, but similar thinking lead me to
add module interface to Jackson. I think it is really really useful to
"upgrade" extensibility from set of methods to use or override, into
sort of external interface, to allow for 3rd party extensions.
It seems to me that jDBI can be useful in such a wide area that maybe
something along same lines could work. It does require quite a bit of
work, iterative design, rewriting etc. But it would make it possible
to have nice integration, without adding close coupling or dependency
hell.

-+ Tatu +-

Reply all
Reply to author
Forward
0 new messages