Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6020 > unrolled thread

Spring/hibernate and JDBC

Back to article view | Back to comp.lang.java.programmer

Contents

  Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 14:56 -0700
    Re: Spring/hibernate and JDBC markspace <-@.> - 2011-07-09 16:01 -0700
      Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 17:29 -0700
        Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:55 -0400
      Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 17:32 -0700
        Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 08:27 -0300
        Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 13:33 +0200
        Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 11:25 -0700
          Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-11 20:44 +0200
          Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-11 16:39 -0700
            Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 17:06 -0700
              Re: Spring/hibernate and JDBC Gene Wirchenko <genew@ocis.net> - 2011-07-11 21:37 -0700
            Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-12 07:01 -0300
            Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:00 -0400
          Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:58 -0400
            Re: Spring/hibernate and JDBC Tom Anderson <twic@urchin.earth.li> - 2011-07-22 17:24 +0100
        Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:52 -0400
      Re: Spring/hibernate and JDBC Tom Anderson <twic@urchin.earth.li> - 2011-07-10 13:34 +0100
        Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 11:08 -0300
          Re: Spring/hibernate and JDBC Stanimir Stamenkov <s7an10@netscape.net> - 2011-07-10 17:45 +0300
            Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 17:35 -0300
        Re: Spring/hibernate and JDBC Steve Sobol <sjsobol@JustThe.net> - 2011-07-10 09:42 -0700
      Re: Spring/hibernate and JDBC Tom <tom400f@gmail.com> - 2011-07-10 22:29 +0000
      Re: Spring/hibernate and JDBC Gunter Herrmann <notformail0106@earthlink.net> - 2011-07-11 10:19 -0400
        Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:09 -0400
    Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 13:24 +0200
      Re: Spring/hibernate and JDBC Elegie <elegie@anonymous.invalid> - 2011-07-10 13:56 +0200
        Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 14:17 +0200
    Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 10:44 -0300
    Re: Spring/hibernate and JDBC Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-07-11 09:52 +0300
    Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 11:31 -0700
      Re: Derby and Java SE (was: Spring/hibernate and JDBC) lewbloch <lewbloch@gmail.com> - 2011-07-11 15:46 -0700
    Re: Spring/hibernate and JDBC iadb <freeinternetarticles@gmail.com> - 2011-07-17 10:17 -0700
    Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:47 -0400
    Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:02 -0400

Page 1 of 2  [1] 2  Next page →

#6020 — Spring/hibernate and JDBC

With spring and hibernate so popular now, is there anybody still only
use JDBC to write database application code? Thanks.

[toc] | [next] | [standalone]

#6021

On 7/9/2011 2:56 PM, Jack wrote:
> With spring and hibernate so popular now, is there anybody still only
> use JDBC to write database application code? Thanks.


I'm sure someone is, but yes I assume that JPA & Hibernate and 
dependency injection frameworks like Spring and JSF have become the norm.

Still good to know what JDBC is and does, since it's used by JPA and 
Hibernate (et al.).

[toc] | [prev] | [next] | [standalone]

#6022

On Jul 9, 4:01 pm, markspace <-@.> wrote:
> On 7/9/2011 2:56 PM, Jack wrote:
>
> > With spring and hibernate so popular now, is there anybody still only
> > use JDBC to write database application code? Thanks.
>
> I'm sure someone is, but yes I assume that JPA & Hibernate and
> dependency injection frameworks like Spring and JSF have become the norm.
>
> Still good to know what JDBC is and does, since it's used by JPA and
> Hibernate (et al.).

What are the pros and cons of using Spring/hibernate and JDBC?

Thanks.

[toc] | [prev] | [next] | [standalone]

#6365

On 7/9/2011 8:29 PM, Jack wrote:
> On Jul 9, 4:01 pm, markspace<-@.>  wrote:
>> On 7/9/2011 2:56 PM, Jack wrote:
>>
>>> With spring and hibernate so popular now, is there anybody still only
>>> use JDBC to write database application code? Thanks.
>>
>> I'm sure someone is, but yes I assume that JPA&  Hibernate and
>> dependency injection frameworks like Spring and JSF have become the norm.
>>
>> Still good to know what JDBC is and does, since it's used by JPA and
>> Hibernate (et al.).
>
> What are the pros and cons of using Spring/hibernate and JDBC?

ORM (incl. Hibernate) provides you with an OO view that fit well
with an OO language like Java and you save a ton of trivial
code.

JDBC supports types of database access that are not object oriented
and are in general easier to follow regarding what is going on.

If the database access is  object oriented then I will recommend
using ORM and if necessary get the developers properly trained.

Arne

[toc] | [prev] | [next] | [standalone]

#6023

On Jul 9, 4:01 pm, markspace <-@.> wrote:
> On 7/9/2011 2:56 PM, Jack wrote:
>
> > With spring and hibernate so popular now, is there anybody still only
> > use JDBC to write database application code? Thanks.
>
> I'm sure someone is, but yes I assume that JPA & Hibernate and
> dependency injection frameworks like Spring and JSF have become the norm.
>
> Still good to know what JDBC is and does, since it's used by JPA and
> Hibernate (et al.).

Is using JDBC to access database more efficient than using
Spring/hibernate?

[toc] | [prev] | [next] | [standalone]

#6036

On 11-07-09 09:32 PM, Jack wrote:
> On Jul 9, 4:01 pm, markspace <-@.> wrote:
>> On 7/9/2011 2:56 PM, Jack wrote:
>>
>>> With spring and hibernate so popular now, is there anybody still only
>>> use JDBC to write database application code? Thanks.
>>
>> I'm sure someone is, but yes I assume that JPA & Hibernate and
>> dependency injection frameworks like Spring and JSF have become the norm.
>>
>> Still good to know what JDBC is and does, since it's used by JPA and
>> Hibernate (et al.).
> 
> Is using JDBC to access database more efficient than using
> Spring/hibernate?

Define "efficiency". Is it runtime efficiency - knowing that you've got
the best possible SQL statement for actual load conditions - or is it
development efficiency - producing adequate DB access code in an
acceptable amount of team time?

There are a number of considerations that come into play. A major one is
the fact that only a minority of developers have sufficient SQL-fu and
also specific RDBMS knowledge to do a better job of writing SQL than a
JPA persistence provider like Hibernate or EclipseLink will. That's to
say, one does not usually observe that standalone native SQL written by
a given programmer is substantially better than the SQL generated from
EJBQL which is written by the _same_ programmer.

In fact, in a dev shop where coders are allowed too free rein to write
native SQL in a JPA context, their SQL is often worse than if they had
expressed their solution within the constraints of EJBQL. Unless they
are top-notch people.

With the latest JPA (version 2.x) there is also a type-safe criteria API
that offers more benefits than what the accessors available on JDBC's
ResultSet and PreparedStatement do. You can certainly do some typesafe
queries with JDBC's DataSet but at this point you're simply edging into
functionality that JPA takes for granted as basic.

In deciding what approach to take, I myself would not worry about
runtime performance excessively, at the gitgo, other than making sure
that regardless of whether the DB access code is in SQL or EJBQL, that
the coders are competent with the underlying fundamentals of accessing
an RDBMS. A coder who is not competent here will write an abortion
either way. To put it another way, the programmer should be capable of
producing good SQL, no matter what, but given that they may in fact
_then_ be better off writing EJBQL in a JPA environment.

Assuming basic competency, you'll really only discover at testing time
what DB accesses are not up to snuff in terms of performance. This would
be true for either straight JDBC (possibly using something like MyBatis,
though) or JPA with Hibernate or EclipseLink. At this stage of the game
your programmers may well engage the help of a DBA for some fine-tuning.
Much of the fine-tuning will have little to do with the actual SQL anyway.

Myself I tend to go with JPA 2, and only those DB accesses that either
cannot be fully expressed in EJBQL, and/or are complex enough that they
are better off in a stored procedure, usually end up in hardcoded SQL
someplace. Bear in mind that modern JPA persistence providers offer a
lot of customization features for finetuning, so it's rare to encounter
a _performance_ situation that forces you to use native SQL.

One larger consideration is persistence management. It is _both_ a pro
and a con of JPA that you place your persistent data, in the form of
objects, under the management of the persistence provider. This is such
a large topic that it's probably best the subject of another thread. But
it's absolutely an important factor in deciding between JPA and straight
JDBC.

AHS

[toc] | [prev] | [next] | [standalone]

#6037

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 10/07/2011 02:32, Jack a écrit :
> Is using JDBC to access database more efficient than using
> Spring/hibernate?

Usually, Hibernate is the very most efficient.

Hibernate use 2 levels of cache to store query results and retrieved
objects.
For example, if you fetch one object, modify it 100×, and then delete
it, Hibernate does only 2 requests : select and delete. All update are
useless.
An other example is retrieving the same object 100× generate only one
select the first time, all others accesses using the Hibernate cache to
find the object.

But Hibernate could be very inefficient if your mapping is badly done.
Lazy loading could collapse your database engine under thousands of
short queries to fetch all children of one object.
On the opposite, eager loading could fetch the ¾ of your database only
with one query.

Hibernate is more efficient if you use it correctly.

- -- 
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOGY4dAAoJEK8zQvxDY4P9dhUH/2FfGAO1NoM1HUEoK8518b8R
KOb4fXcEwE6L19SAOIrPWngbuhtdq1InO/we7sDogUfsqQJVyIGLT26hJ37e6Ppi
V27IYabTMMC+GMaPAx3mK7JnHr26T6+UvlaoENdJ5zzV/1yCZZLuBglSrOg24nsg
QiTd71rqMe7Vnjuaiurxr473vaVX3jASRoi0Y0lHvsBbX4cyognO3pxV/fzD0v+R
9+MbbqE0JnReU99BP9s0vlrpJy2tioQzT0KP0pPJHwHQU8eBkyOsT7A54jxrxJRf
L/5G6EoEQgLKLRVsT/mMKW8jowIyYDtX4wBxb/xGQtLxbDFGjhppCwYWAnby44Q=
=puE0
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#6079

On Jul 9, 5:32 pm, Jack <junw2...@gmail.com> wrote:
> On Jul 9, 4:01 pm, markspace <-@.> wrote:
>
> > On 7/9/2011 2:56 PM, Jack wrote:
>
> > > With spring and hibernate so popular now, is there anybody still only
> > > use JDBC to write database application code? Thanks.
>
> > I'm sure someone is, but yes I assume that JPA & Hibernate and
> > dependency injection frameworks like Spring and JSF have become the norm.
>
> > Still good to know what JDBC is and does, since it's used by JPA and
> > Hibernate (et al.).
>
> Is using JDBC to access database more efficient than using
> Spring/hibernate?

Yes and no.  It can be more efficient as a programmer to use Hibernate
(but don't use Spring!), at least if you stay with the JPA-compliant
parts of Hibernate.  It can run more efficiently to use JDBC without
JPA, but usually is not.

Unfortunately, most use of Hibernate in the wild is quite ignorant and
harms the respective projects.  I have yet to encounter intelligent
use of Spring in a real project.

Good use of JPA will make your program quite clean and maintainable,
i.e., very efficient in the development and maintenance dimensions.
Bad use of JPA, like bad use of a chain saw, results in a horror-movie
scenario.  For certain bulk operations, JDBC is better.

Asking about "efficiency" for use of JPA vs. JDBC calls is like asking
if it's more efficient to use an automobile than a bicycle.  The use
cases differ, so where one is more appropriate the other is less so,
and "efficiency" has little to nothing to do with it.  That is to say,
"efficiency with respect to what?" is your real question.

So, efficiency with respect to what?

Use JPA when you want to code to an object model that persists itself,
without regard for the data-centric point of view.  Use JDBC when you
need a relational model of your persistent data.

Eschew Spring.

--
Lew

[toc] | [prev] | [next] | [standalone]

#6081

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 11/07/2011 20:25, lewbloch a écrit :
> I have yet to encounter intelligent
> use of Spring in a real project.

Spring is only usefull for IoC to do a n-tier application (domain, dao,
service).
Spring is totally bloated and useless when you use it for its Hibernate
tools (Hibernate template and others).

- -- 
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOG0RrAAoJEK8zQvxDY4P9+mcH/3doZ2PuHCWEJx3rWHptLlNt
xkuHpEMFaYfWaT3DsjdNDlgpxodatvLs1/zDp1BOpDpawFkRVWmTbcQePojCCDx5
SQoXxQGgCG2mxKQfB3zx7jjLZCIG1AShMP2wkN6qROwfvPHTDsHwRsoJMyPca346
3IFNQZQ8H/YCsjTupfmrUxhsrJipwr04usgYkvAu4BMqZbGXTVSrpa4oiUkMNw32
8RbRgPxjW7+V5Ibrjfy1n8sSptwEa2DM893vbxMBbhejudDLLlGCg7CimsYDhFkU
JDznZxtCpit3Mnu27HQVE4J89/gLTPkSaFXDqIOMlNM/mnbmppHSo+Ydwt/8Kx4=
=owYR
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#6093

On Jul 11, 11:25 am, lewbloch <lewbl...@gmail.com> wrote:
> On Jul 9, 5:32 pm, Jack <junw2...@gmail.com> wrote:
>
> > On Jul 9, 4:01 pm, markspace <-@.> wrote:
>
> > > On 7/9/2011 2:56 PM, Jack wrote:
>
> > > > With spring and hibernate so popular now, is there anybody still only
> > > > use JDBC to write database application code? Thanks.
>
> > > I'm sure someone is, but yes I assume that JPA & Hibernate and
> > > dependency injection frameworks like Spring and JSF have become the norm.
>
> > > Still good to know what JDBC is and does, since it's used by JPA and
> > > Hibernate (et al.).
>
> > Is using JDBC to access database more efficient than using
> > Spring/hibernate?
>
> Yes and no.  It can be more efficient as a programmer to use Hibernate
> (but don't use Spring!), at least if you stay with the JPA-compliant
> parts of Hibernate.  It can run more efficiently to use JDBC without
> JPA, but usually is not.
>
> Unfortunately, most use of Hibernate in the wild is quite ignorant and
> harms the respective projects.  I have yet to encounter intelligent
> use of Spring in a real project.
>
> Good use of JPA will make your program quite clean and maintainable,
> i.e., very efficient in the development and maintenance dimensions.
> Bad use of JPA, like bad use of a chain saw, results in a horror-movie
> scenario.  For certain bulk operations, JDBC is better.
>
> Asking about "efficiency" for use of JPA vs. JDBC calls is like asking
> if it's more efficient to use an automobile than a bicycle.  The use
> cases differ, so where one is more appropriate the other is less so,
> and "efficiency" has little to nothing to do with it.  That is to say,
> "efficiency with respect to what?" is your real question.
>
> So, efficiency with respect to what?

Certainly using spring/hibernate has a shorter development circle than
JDBC and the code is easier to maintain.
Here for efficiency, I mean performance. For a server with frequent
and large amount of database accesses(insert/delete/update), which way
has a better performance?

[toc] | [prev] | [next] | [standalone]

#6094

On Jul 11, 4:39 pm, Jack <junw2...@gmail.com> wrote:
> Certainly using spring [sic]/hibernate [sic] has a shorter development circle than
> JDBC and the code is easier to maintain.

Not in my experience.  Badly written Spring code, which is all I've
ever seen, is terribly difficult, lengthy and expensive to maintain.
Badly written Hibernate code, which I have seen, likewise.  The
majority of Hibernate code I've seen (across several projects that
used it) was all badly written.  The problem came about with Hibernate
because people used it in lieu of SQL (i.e., raw JDBC calls) rather
than to support an object model.

> Here for efficiency, I mean performance. For a server with frequent
> and large amount of database accesses(insert/delete/update), which way
> has a better performance?

That depends, and has been answered upthread.  Properly used, JPA-
based code (including Hibernate) can be faster than raw JDBC,
depending on the use patterns.  Only you can answer this question.  We
cannot, based on the paucity of information you provide about your
scenario(s).  Your question is like asking, "Which relieves pain
better, aspirin or acetaminophen/codeine?"  The answer depends on the
problem you're trying to solve.

The question you should be asking is which one suits your logic
better.  Do you need to maintain an object model that must persist?
Chances are that Hibernate is useful and will help you - IF YOU KNOW
WHAT YOU'RE DOING!  If you don't, neither Hibernate nor JDBC can save
you.

The key is that JPA (don't use "native" Hibernate!) supports an object-
oriented model; JDBC supports a set-oriented model.  When set
operations are needed, JPA gets in the way.  When object-oriented
operations are needed, JDBC gets in the way.  Use what's right for the
problem.  You will never (NEVER!) get a reliable answer to "which has
better performance?" unless you write your code correctly (!),
appropriately to the programming model and MEASURE the performance.

Development and maintenance costs are more important than tiny
differences in runtime cost.  You might find that there is no
measurable difference at runtime.  Code correctly first, and only
address performance in the face of a demonstrated bottleneck.

Stop repeating your question until you've assimilated the good answers
you've already received, please.

--
Lew

[toc] | [prev] | [next] | [standalone]

#6099

On Mon, 11 Jul 2011 17:06:37 -0700 (PDT), lewbloch
<lewbloch@gmail.com> wrote:

[snip]

>Stop repeating your question until you've assimilated the good answers
>you've already received, please.

     And this may help you pose more useful questions:
          http://www.catb.org/~esr/faqs/smart-questions.html
          How To Ask Questions The Smart Way
          by Eric Steven Raymond

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#6108

On 11-07-11 08:39 PM, Jack wrote:
> On Jul 11, 11:25 am, lewbloch <lewbl...@gmail.com> wrote:
[ SNIP ]

>>
>> Asking about "efficiency" for use of JPA vs. JDBC calls is like asking
>> if it's more efficient to use an automobile than a bicycle.  The use
>> cases differ, so where one is more appropriate the other is less so,
>> and "efficiency" has little to nothing to do with it.  That is to say,
>> "efficiency with respect to what?" is your real question.
>>
>> So, efficiency with respect to what?
> 
> Certainly using spring/hibernate has a shorter development circle than
> JDBC and the code is easier to maintain.

You can probably find a tutorial/example scenario, or a specific toy
application, that fosters the impression that Spring+Hibernate has a
shorter development cycle than JDBC, and is easier to maintain.

In general it's my belief that the opposite is true, and that's with
Hibernate (or EclipseLink) only, not even including Spring. The use of
Spring substantially adds to the maintenance burden of an application;
I'll leave off discussing it because I don't know why anyone wants to
use it these days.

A fair comparison of JDBC versus JPA has to assume that competent
developers are applying best practices to both. In either case a data
access layer (DAL) will contain the persistence code; the rest of the
application simply sees domain objects and uses "repository" methods to
do things with them. As much thought and effort goes into deciding what
domain classes will be exposed to the rest of an app by a JPA-based DAL
as for a JDBC-based DAL.

Of course you might be thinking of not using a DAL at all, and using JPA
directly in every layer. That's a prescription for maintenance problems
straight off. I recommend against it...although I think I might be a
voice in the wilderness on this point.

JPA is _not_ easier to use than JDBC. It may often be less _laborious_
to use, but that's for one-time only coding anyway. But JPA as an API
that has to be understood well is not easier than JDBC. This goes
directly to the maintenance argument.

> Here for efficiency, I mean performance. For a server with frequent
> and large amount of database accesses(insert/delete/update), which way
> has a better performance?

Neither, or both. In all cases that type of performance depends on the
instructions sent to the DB, and generally speaking both JDBC and JPA
can issue the same instructions. That type of performance depends on the
competence of your developers.

AHS

[toc] | [prev] | [next] | [standalone]

#6367

On 7/11/2011 7:39 PM, Jack wrote:
> Certainly using spring/hibernate has a shorter development circle than
> JDBC and the code is easier to maintain.

Only if the developer knows Hibernate.

(Spring is many things so unless you qualify what part of Spring you are
talking about then it is pointless to discuss)

> Here for efficiency, I mean performance. For a server with frequent
> and large amount of database accesses(insert/delete/update), which way
> has a better performance?

Hibernate should perform as well as JDBC, but see above.

Arne

[toc] | [prev] | [next] | [standalone]

#6366

On 7/11/2011 2:25 PM, lewbloch wrote:
>                                  I have yet to encounter intelligent
> use of Spring in a real project.

> Eschew Spring.

Spring can be very nice if you only use the original Spring stuff (*).

The problem is if you try to use all the Spring stuff, because a
gazillion relative unrelated stuff got bundled into Spring.

Arne

*) Maybe CDI will remove the need for even the original Spring stuff,
    but CDI is still pretty new.

[toc] | [prev] | [next] | [standalone]

#6401

[Multipart message — attachments visible in raw view] — view raw

On Thu, 21 Jul 2011, Arne Vajhøj wrote:

> On 7/11/2011 2:25 PM, lewbloch wrote:
>
>> I have yet to encounter intelligent use of Spring in a real project.
>>
>> Eschew Spring.
>
> Spring can be very nice if you only use the original Spring stuff (*).
>
> The problem is if you try to use all the Spring stuff, because a
> gazillion relative unrelated stuff got bundled into Spring.
>
> *) Maybe CDI will remove the need for even the original Spring stuff,
>   but CDI is still pretty new.

True. EJB3 also took a big step into Spring's space. It is different to 
Spring in some large ways and some small ways, but it's pretty widely 
supported, and is something to consider.

If CDI had been invented several years ago, the world would be a better 
place. I recently got involved with a question about using CDI to 
configure a JBoss JMX service:

http://stackoverflow.com/q/6723260/116639

And it struck me that the wheel of configuring object instances from has 
not only been reinvented a tragic number of times, but it's even been 
reinvented several times within a single project or platform, like JBoss 
or J2EE. Something like CDI (maybe something a bit bigger - i think you 
need a uniform way to use files to drive configuration, alongside 
autowiring), done well, could have preempted all those inventions, and 
saved a huge amount of time and wailing and gnashing of teeth.

tom

-- 
What we learn about is not nature itself, but nature exposed to our
methods of questioning. -- Werner Heisenberg

[toc] | [prev] | [next] | [standalone]

#6362

On 7/9/2011 8:32 PM, Jack wrote:
> On Jul 9, 4:01 pm, markspace<-@.>  wrote:
>> On 7/9/2011 2:56 PM, Jack wrote:
>>> With spring and hibernate so popular now, is there anybody still only
>>> use JDBC to write database application code? Thanks.
>>
>> I'm sure someone is, but yes I assume that JPA&  Hibernate and
>> dependency injection frameworks like Spring and JSF have become the norm.
>>
>> Still good to know what JDBC is and does, since it's used by JPA and
>> Hibernate (et al.).
>
> Is using JDBC to access database more efficient than using
> Spring/hibernate?

As Hibernate is using JDBC then in theory JDBC will always
be at least as fast as Hibernate.

In practice I would say that Hibernate is often as fast
as manually written JDBC code but occasionally much slower.

When it is much slower it is typical because:
- the developer did not understand hibernate sufficiently
   well (it is very typical for ORM to be very easy to get
   the code working but it requires deep understanding to
   actually get it working right - because the ORM hides
   what is going on behind the scenes)
- the task was not suited for ORM

Arne

[toc] | [prev] | [next] | [standalone]

#6042

On Sat, 9 Jul 2011, markspace wrote:

> On 7/9/2011 2:56 PM, Jack wrote:
>
>> With spring and hibernate so popular now, is there anybody still only 
>> use JDBC to write database application code? Thanks.
>
> I'm sure someone is, but yes I assume that JPA & Hibernate and 
> dependency injection frameworks like Spring and JSF have become the 
> norm.

This has also been my impression. On my current project, we do still write 
raw SQL using JDBC on occasion, but only because we need to do some sort 
of mad query that can't be done with our persistence provider. For 
instance, we have a query that runs every hour to update our list of 
top-selling products, which joins together all sorts of tables and inserts 
the result directly into a table. I don't think there's any way to do that 
(up to and including inserting from the select) with JPA.

Now, having said that, it appears that somebody doesn't see raw JDBC as 
being limited to corner cases, because they've steadily been adding 
features to it. Features i find quite baffling. Here's what's coming in 
JDK 7 (skip over the try-with-resources stuff, which is great, but not 
baffling):

http://download.java.net/jdk7/docs/technotes/guides/jdbc/jdbc_41.html

Who is the target market for this RowSetFactory stuff? In fact, who is the 
target market for the existing RowSets? We have CachedRowSet, 
FilteredRowSet, JoinRowSet, JdbcRowSet (!), and WebRowSet - none of which 
i have ever seen used or advocated. Who is using these, and what for?

The javadoc for JdbcRowSet says:

  A wrapper around a ResultSet object that makes it possible to use the
  result set as a JavaBeansTM component. Thus, a JdbcRowSet object can be
  one of the Beans that a tool makes available for composing an
  application.

Waitwhat? Tools composing applications out of JavaBeans? Wasn't that idea 
dead in, like, 1998? What the hell is going on here? Is there some mad 
backwater Lost World of Java development where people are actually 
building apps by dragging icons around in tools?

tom

-- 
Everyone has to die sooner or later, whether they be killed by germs,
crushed by a collapsing house, or blown to smithereens by an atom bomb. --
Mao Zedong

[toc] | [prev] | [next] | [standalone]

#6046

On 11-07-10 09:34 AM, Tom Anderson wrote:
> On Sat, 9 Jul 2011, markspace wrote:
> 
>> On 7/9/2011 2:56 PM, Jack wrote:
>>
>>> With spring and hibernate so popular now, is there anybody still only
>>> use JDBC to write database application code? Thanks.
>>
>> I'm sure someone is, but yes I assume that JPA & Hibernate and
>> dependency injection frameworks like Spring and JSF have become the norm.
> 
> This has also been my impression. On my current project, we do still
> write raw SQL using JDBC on occasion, but only because we need to do
> some sort of mad query that can't be done with our persistence provider.
> For instance, we have a query that runs every hour to update our list of
> top-selling products, which joins together all sorts of tables and
> inserts the result directly into a table. I don't think there's any way
> to do that (up to and including inserting from the select) with JPA.

Short of using features that are peculiar to an implementation, it seems
to me that if you had that result table described as a JPA entity, you
could use an EJBQL constructor expression to load up the to-be-inserted
entities from that mess of joins. Persist _those_.

Just a thought. In real life I'd probably write the guts as a stored
proc, and have it run with a DB scheduler like Oracle Scheduler.

> Now, having said that, it appears that somebody doesn't see raw JDBC as
> being limited to corner cases, because they've steadily been adding
> features to it. Features i find quite baffling. Here's what's coming in
> JDK 7 (skip over the try-with-resources stuff, which is great, but not
> baffling):
> 
> http://download.java.net/jdk7/docs/technotes/guides/jdbc/jdbc_41.html
> 
> Who is the target market for this RowSetFactory stuff? In fact, who is
> the target market for the existing RowSets? We have CachedRowSet,
> FilteredRowSet, JoinRowSet, JdbcRowSet (!), and WebRowSet - none of
> which i have ever seen used or advocated. Who is using these, and what for?
> 
> The javadoc for JdbcRowSet says:
> 
>  A wrapper around a ResultSet object that makes it possible to use the
>  result set as a JavaBeansTM component. Thus, a JdbcRowSet object can be
>  one of the Beans that a tool makes available for composing an
>  application.
> 
> Waitwhat? Tools composing applications out of JavaBeans? Wasn't that
> idea dead in, like, 1998? What the hell is going on here? Is there some
> mad backwater Lost World of Java development where people are actually
> building apps by dragging icons around in tools?
> 
> tom
> 
Seems like VisualStudio envy to me. And way behind the curve at that.

AHS

[toc] | [prev] | [next] | [standalone]

#6047

Sun, 10 Jul 2011 11:08:01 -0300, /Arved Sandstrom/:
> On 11-07-10 09:34 AM, Tom Anderson wrote:
>
>> This has also been my impression. On my current project, we do still
>> write raw SQL using JDBC on occasion, but only because we need to do
>> some sort of mad query that can't be done with our persistence provider.
>> For instance, we have a query that runs every hour to update our list of
>> top-selling products, which joins together all sorts of tables and
>> inserts the result directly into a table. I don't think there's any way
>> to do that (up to and including inserting from the select) with JPA.
>
> Short of using features that are peculiar to an implementation, it seems
> to me that if you had that result table described as a JPA entity, you
> could use an EJBQL constructor expression to load up the to-be-inserted
> entities from that mess of joins. Persist _those_.

I was just about to ask whether one have used such Constructor 
Expressions in real life:

http://download.oracle.com/javaee/5/tutorial/doc/bnbuf.html#bnbwc
http://download.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnbwc

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web