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

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

Apache JDBC utils

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

Contents

  Apache JDBC utils markspace <-@.> - 2012-04-30 14:55 -0700
    Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-30 20:56 -0300
      Re: Apache JDBC utils markspace <-@.> - 2012-04-30 17:50 -0700
    Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-04-30 18:03 -0700
      Re: Apache JDBC utils markspace <-@.> - 2012-04-30 19:27 -0700
        Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-01 10:29 -0300
          Re: Apache JDBC utils markspace <-@.> - 2012-05-01 08:57 -0700
            Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-05-02 11:16 -0700
              Re: Apache JDBC utils markspace <-@.> - 2012-05-03 07:51 -0700
      Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-01 19:22 -0400
    Re: Apache JDBC utils Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-01 10:32 -0700
      Re: Apache JDBC utils markspace <-@.> - 2012-05-01 11:22 -0700
        Re: Apache JDBC utils Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-01 15:26 -0700
          Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-01 19:44 -0300
    Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-01 19:26 -0400
      Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-01 21:14 -0300
        Re: Apache JDBC utils Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-05-01 22:22 -0500
          Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 13:52 -0400
        Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 13:51 -0400
          Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-03 17:11 -0300
            Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 16:58 -0400
              Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-03 18:25 -0300
                Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 19:55 -0400
      Re: Apache JDBC utils Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-05-01 22:08 -0500
        Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 13:55 -0400
          Re: Apache JDBC utils Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-05-03 13:44 -0500
            Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 15:06 -0400
    Re: Apache JDBC utils "John B. Matthews" <nospam@nospam.invalid> - 2012-05-01 23:37 -0400
      Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-02 07:37 -0300
        Re: Apache JDBC utils "John B. Matthews" <nospam@nospam.invalid> - 2012-05-02 18:51 -0400
    Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-02 12:22 +0200
      Re: Apache JDBC utils markspace <-@.> - 2012-05-02 08:29 -0700
        Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-02 22:02 +0200
          Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-05-02 14:22 -0700
            Re: Apache JDBC utils Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-02 18:53 -0300
            Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 00:03 +0200
              Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 00:14 +0200
              Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 00:27 +0200
                Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 14:03 -0400
              Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-02 18:58 -0400
              Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-05-02 16:18 -0700
            Re: Apache JDBC utils Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-02 15:25 -0700
              Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 00:59 +0200
                Re: Apache JDBC utils Arne Vajhøj <arne@vajhoej.dk> - 2012-05-03 14:05 -0400
              Re: Apache JDBC utils Lew <lewbloch@gmail.com> - 2012-05-02 16:24 -0700
                Re: Apache JDBC utils Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-02 16:35 -0700
                Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 01:46 +0200
                Re: Apache JDBC utils Jan Burse <janburse@fastmail.fm> - 2012-05-03 01:49 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14216

On 5/3/2012 4:11 PM, Arved Sandstrom wrote:
> On 12-05-03 02:51 PM, Arne Vajhøj wrote:
>> On 5/1/2012 8:14 PM, Arved Sandstrom wrote:
>>> On 12-05-01 08:26 PM, Arne Vajhøj wrote:
>>>> On 4/30/2012 5:55 PM, markspace wrote:
>>>>> I'm making a small website as a personal project using only the JDBC
>>>>> interface. (No ORM, etc.) Well, I did the CRUD for exactly one bean and
>>>>> found it pretty tedious going. So I started looking around for
>>>>> something
>>>>> light-weight to help me out. I found the Apache commons dbutils
>>>>> project:
>>>>>
>>>>> <http://commons.apache.org/dbutils/>
>>>>
>>>>> And: is there a better, light-weight non-ORM package that you might
>>>>> recommend instead? Something a bit more complete.
>>>>
>>>> What are you actually gaining by not using a full blown ORM
>>>> (JPA, traditional Hibernate etc.)?
>>>
>>> Precisely so that you don't have a full-blown ORM with either a native
>>> API or JPA. I'll give you an example: I do integrations with lightweight
>>> ESBs [1], and sometimes I might have to write some simple JDBC in
>>> components and all I want are some Java Beans to represent the ResultSet
>>> rows. Just for packaging. Something like DBUtils could be handy (in fact
>>> I'm delighted that markspace reminded me of this handy API). I
>>> definitely don't want a full-blown JPA ORM in that environment.
>>>
>>> Like I said in another post, if you make an argument that a full-blown
>>> ORM is always preferable to a lightweight one, that's practically
>>> tantamount to saying that it never makes sense to use JDBC either.
>>
>> If we are talking about "single row centric" then I would go for
>> either the heavy ORM to get functionality or plain JDBC to avoid
>> dependency (the last argument is more or less a SE only argument).
>> I would find it difficult to see a good argument for going with
>> the light ORM.
>>
>> For "multi row centric" then I would go for plain JDBC as
>> ORM is not intended for that.
>
> I think I'd analyze it probably the same way. Usually.
>
> However, the situation I am describing here - it's one example, there
> are others - is one where I don't want JPA or native ORM units-of-work
> or anything barely above raw JDBC. It's simply the case that from time
> to time I might want to package a ResultSet row as an object, with zero
> special meaning. That's all I'm saying.
>
> It's not like I often have this requirement. 90+ percent of the tiem
> it's JPA for me, almost all of the rest is plain JDBC. Using a simple OR
> mapper like DBUtils would be very occasional.

Hard to argue against anything being a good choice "very occasional".

Occasionally the requirements are slightly different than the usual.

>>>> I doubt that you will save any code in your app.
>>>
>>> Likely not. That's not why you'd pick a rudimentary mapper.
>>>
>>>> I doubt that the less memory usage will be noticeable.
>>>
>>> Likely not. It's not why I'd make a decision.
>>>
>>>> It is not really a problem that the full blown ORM is hundreds
>>>> of thousands of lines of code, because maintenance is not
>>>> your responsibility.
>>>
>>> It's not, no. But that full-blown ORM with 500,000 lines of code (pretty
>>> close to what EclipseLink 2.2 has in its 'org' package [2]) is going to
>>> have quite a few more defects than an ORM with 5,000 lines of code
>>> (DBUtils has about 8,000 [2]).
>>
>> That is obvious true, but I don't know if it is relevant.
>>
>> If we follow the traditional rule of 1 bug per 1000 lines
>> of code, then we will see:
>>
>> 500 KLOC =>  500 bugs
>> 5 KLOC =>  5 bugs
>>
>> But there are two things to remember:
>> 1) The same usage will only use a smaller portion of the large library.
>> 2) This is when delivered first time. Bugs get fixed as they get found.
>>     The more the code is used the faster the bugs get found.
>>
>> If we compare the 500 KLOC library with the 5 KLOC library then
>> doing what the small library can do may only use 25 or 50 KLOC of
>> the large library.
>>
>> If that is the case and the larger library is used so much more than
>> the smaller library (and the functionality of the larger library
>> that can be done by the smaller library is most likely the
>> functionality most used) that there are 5 or 10 times less bugs
>> left per size, then there may actually be fewer bugs left.
>>
>> Is this just number magic? I don't think so!
>>
>> If you want a stable OS and a stable database would you go for
>> an exotic product with a small code base or a well known
>> product with a much larger code base?
>
> The LOC count isn't one that I'd use to make the decision, Arne.
> Although I'd certainly read the bug database to find out what could hurt.
>
> You mentioned maintenance, not me, and I know from bitter experience
> that ORM problems are *my* problems.
>
> But I'll reiterate that if I went with a small, very rudimentary mapper
> that it would be special case and a situation where a full-blown ORM
> would be massive overkill.

Yes.

And I am sure that such cases do exist.

I am just trying to argue that in most cases a big
jar files is not a problem in itself.

>>> No particular aspersions on EclipseLink, but when one of those defects
>>> is hurting *your* project, even with access to source it's not
>>> straightforward to fix it, and it's not an overnighter to get the EL
>>> team to do so either. With as few lines of code are in DBUtils source,
>>>
>>> *I* can fix it, and readily.
>>
>> I would not want to fix it. I would want something where you can report
>> the bug to someone and let them fix it.
>
> You have no real choice with a large ORM anyway. You report it, and if
> you're lucky a few minor versions down the pipe and a few months later
> you see a fix.

This is the industry way.

>>>> And some of the capabilities (like caching) could become
>>>> very handy in the future.
>>>
>>> The operative word being "could". Leaving aside the other management
>>> capabilities of the persistence context Level 1 cache, like uniqueness
>>> of identity within a PC, if you are constructing objects with a simple
>>> mapper like DBUtils you *have* a cache. Your objects are in memory;
>>> you're not hitting the DB every time you need them.
>>
>> That is not really level 1 cache.
>
> What do you consider to be a cache? A cache means that you've got your
> stuff in a storage area that's faster to access than the original
> location. Usually memory. If I get my stuff through JDBC, and access
> data afterwards off the ResultSet, that's a cache. If I convert that
> ResultSet to a collection of objects, and access data in that collection
> afterwards, that's a cache.
>
> Insofar as this level of caching is similar to a persistence context,
> which is referred to as Level 1 in JPA, I have no problems thinking of
> it as Level 1 equivalent.

I would define an ORM cache as a cache in the ORM code not a cache
in my code.

Otherwise any ORM would have a cache since the O will be in memory.

>>> As for JPA Level 2, well, that's a decision best approached carefully
>>> and not made available by default. I surely don't think you need to go
>>> with JPA just in case you might need Level 2 cache at some point.
>>
>> If it was just that: no. But there are other features that also could
>> become useful.
>
> Hopefully you know what you need early on, considering as how you did
> good requirements analysis. In which case you're using JPA because you
> already know you need it.

I don't think I have ever seen requirements that actually covered
all requirements for the actual lifetime of the application.

Arne

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

#14222

On 12-05-03 05:58 PM, Arne Vajhøj wrote:
> On 5/3/2012 4:11 PM, Arved Sandstrom wrote:
>> On 12-05-03 02:51 PM, Arne Vajhøj wrote:
>>> On 5/1/2012 8:14 PM, Arved Sandstrom wrote:
>>>> On 12-05-01 08:26 PM, Arne Vajhøj wrote:
[ SNIP ]

>>>>> And some of the capabilities (like caching) could become
>>>>> very handy in the future.
>>>>
>>>> The operative word being "could". Leaving aside the other management
>>>> capabilities of the persistence context Level 1 cache, like uniqueness
>>>> of identity within a PC, if you are constructing objects with a simple
>>>> mapper like DBUtils you *have* a cache. Your objects are in memory;
>>>> you're not hitting the DB every time you need them.
>>>
>>> That is not really level 1 cache.
>>
>> What do you consider to be a cache? A cache means that you've got your
>> stuff in a storage area that's faster to access than the original
>> location. Usually memory. If I get my stuff through JDBC, and access
>> data afterwards off the ResultSet, that's a cache. If I convert that
>> ResultSet to a collection of objects, and access data in that collection
>> afterwards, that's a cache.
>>
>> Insofar as this level of caching is similar to a persistence context,
>> which is referred to as Level 1 in JPA, I have no problems thinking of
>> it as Level 1 equivalent.
> 
> I would define an ORM cache as a cache in the ORM code not a cache
> in my code.
> 
> Otherwise any ORM would have a cache since the O will be in memory.

Fair enough. :-) I pretty much figured that's what you were getting at.
Still, when looking at all the cache offerings out there it's worth
recalling from time to time what they really do.

>>>> As for JPA Level 2, well, that's a decision best approached carefully
>>>> and not made available by default. I surely don't think you need to go
>>>> with JPA just in case you might need Level 2 cache at some point.
>>>
>>> If it was just that: no. But there are other features that also could
>>> become useful.
>>
>> Hopefully you know what you need early on, considering as how you did
>> good requirements analysis. In which case you're using JPA because you
>> already know you need it.
> 
> I don't think I have ever seen requirements that actually covered
> all requirements for the actual lifetime of the application.
> 
> Arne
> 
Nor have I. Although I contend that you should understand your
persistence requirements well enough to know whether JPA is called for.
In fact it's almost always a safe bet; you pretty much need some
concrete reasons *not* to use it [1]. IMO.

AHS

1. Maybe you're writing a JPA implementation, say. :-)
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

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

#14235

On 5/3/2012 5:25 PM, Arved Sandstrom wrote:
> On 12-05-03 05:58 PM, Arne Vajhøj wrote:
>> On 5/3/2012 4:11 PM, Arved Sandstrom wrote:
>>> On 12-05-03 02:51 PM, Arne Vajhøj wrote:
>>>> On 5/1/2012 8:14 PM, Arved Sandstrom wrote:
>>>>> As for JPA Level 2, well, that's a decision best approached carefully
>>>>> and not made available by default. I surely don't think you need to go
>>>>> with JPA just in case you might need Level 2 cache at some point.
>>>>
>>>> If it was just that: no. But there are other features that also could
>>>> become useful.
>>>
>>> Hopefully you know what you need early on, considering as how you did
>>> good requirements analysis. In which case you're using JPA because you
>>> already know you need it.
>>
>> I don't think I have ever seen requirements that actually covered
>> all requirements for the actual lifetime of the application.
>>
> Nor have I. Although I contend that you should understand your
> persistence requirements well enough to know whether JPA is called for.
> In fact it's almost always a safe bet; you pretty much need some
> concrete reasons *not* to use it [1]. IMO.

I think we are in violent agreement now.

> 1. Maybe you're writing a JPA implementation, say. :-)

:-)

Arne

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

#14123

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> What are you actually gaining by not using a full blown ORM
> (JPA, traditional Hibernate etc.)?

Simpler project dependencies, direct control over the SQL, less
"architectural weigth", "nærhet til materialet". 

*shrugs* None of those would normally make me forego the convenience
and utility of a full ORM, but they are still gains.

> I doubt that the less memory usage will be noticeable.

Well, there's Android development.
 
> It is not really a problem that the full blown ORM is hundreds
> of thousands of lines of code, because maintenance is not
> your responsibility.

Well, maintenance _of_ the ORM might still affect your project
and need to be managed, though.

-- 
Leif Roar Moldskred

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

#14202

On 5/1/2012 11:08 PM, Leif Roar Moldskred wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> What are you actually gaining by not using a full blown ORM
>> (JPA, traditional Hibernate etc.)?
>
> Simpler project dependencies, direct control over the SQL, less
> "architectural weigth", "nærhet til materialet".

True.

But how much does this really impact things in the real world?

> *shrugs* None of those would normally make me forego the convenience
> and utility of a full ORM, but they are still gains.
>
>> I doubt that the less memory usage will be noticeable.
>
> Well, there's Android development.

OK.

In that context memory footprint may be important.

>> It is not really a problem that the full blown ORM is hundreds
>> of thousands of lines of code, because maintenance is not
>> your responsibility.
>
> Well, maintenance _of_ the ORM might still affect your project
> and need to be managed, though.

True.

But I can not see anything being better than JPA in relation
to having a stable API where changes to the ORM does not require
changes in the ones own code base.

Arne

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

#14207

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/1/2012 11:08 PM, Leif Roar Moldskred wrote:
>>
>> Simpler project dependencies, direct control over the SQL, less
>> "architectural weigth", "nærhet til materialet".
> 
> True.
> 
> But how much does this really impact things in the real world?

I'd say it's not an insignificant impact. For instance, I know I have
spent a surprising amount of time wrangling with dependency management
in Java projects, and I believe every project should carefully
consider how much architectural weight to pull in. 

Direct control over the SQL is one of those issues that you usually
won't need at all, but when you do need it, you _really_ need it [1].

As for "nærhet til materialet" (for those watching from home, an
English translation would be "[staying] close to the subject matter"),
I've personally come to think of that as a cornerstone of good,
readable code. Not an overarching concern, but one of the key concepts
you should always keey in the back of your mind as you write code and
balance and trade-off against appropriately.
 
> True.
> 
> But I can not see anything being better than JPA in relation
> to having a stable API where changes to the ORM does not require
> changes in the ones own code base.

Possibly, but some other ORMs, like Hibernate, have been about as
stable as clay.


[1] The real problem with ORMs here is perhaps not so much that they
prevent you from getting down to the metal with the database, but that
you end up with hardly any developers who has the raw database skills
to do it.

I think one can make an argument that to use an ORM efficently,
_someone_ on the team needs to have a good grounding in fundamental
database theory, but new developers don't get that grounding from
developing with an ORM.


-- 
Leif Roar Moldskred

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

#14209

On 5/3/2012 2:44 PM, Leif Roar Moldskred wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 5/1/2012 11:08 PM, Leif Roar Moldskred wrote:
>> True.
>>
>> But I can not see anything being better than JPA in relation
>> to having a stable API where changes to the ORM does not require
>> changes in the ones own code base.
>
> Possibly, but some other ORMs, like Hibernate, have been about as
> stable as clay.

I have also been burned by a couple of Apache projects.

But while we often complain that the JCP process is too slow and that
they are too conservative, then avoiding too many breaking changes
is one big benefit of what they do.

> [1] The real problem with ORMs here is perhaps not so much that they
> prevent you from getting down to the metal with the database, but that
> you end up with hardly any developers who has the raw database skills
> to do it.
>
> I think one can make an argument that to use an ORM efficently,
> _someone_ on the team needs to have a good grounding in fundamental
> database theory, but new developers don't get that grounding from
> developing with an ORM.

I completely agree.

ORM's is a productivity tool but developer should still
have a good database and SQL understanding.

One thing that makes me dislike an ORM is if it comes
with a foobarQL where you can not get to see the real
SQL send to the database.

Arne

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

#14125

In article <jnn1pc$33c$1@dont-email.me>, markspace <-@.> wrote:

> And: is there a better, light-weight non-ORM package that you might 
> recommend instead?  Something a bit more complete.

Having always used JDBC, I wanted to see what a persistence unit looked 
like. I used the "New Entity Classes from Database Wizard" in NetBeans 
to generate an entity for a database table named CUSTOMER and clicked 
the persistence unit button to generate a JPA controller.

Entity -> Customer.java
Persistence unit -> CustomerJpaController.java

Then I used these two classes to fill a JComboBox model, as shown here:

<http://stackoverflow.com/a/2531942/230513>

The example was easy to create, and I can see several things:

1. The queries, getters, setters and annotations generated in the entity.

2. The findCustomerXxx, create, edit and destroy methods generated in 
the controller, which appear to correspond roughly to select, insert, 
update and delete.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

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

#14127

On 12-05-02 12:37 AM, John B. Matthews wrote:
> In article <jnn1pc$33c$1@dont-email.me>, markspace <-@.> wrote:
> 
>> And: is there a better, light-weight non-ORM package that you might 
>> recommend instead?  Something a bit more complete.
> 
> Having always used JDBC, I wanted to see what a persistence unit looked 
> like. I used the "New Entity Classes from Database Wizard" in NetBeans 
> to generate an entity for a database table named CUSTOMER and clicked 
> the persistence unit button to generate a JPA controller.
> 
> Entity -> Customer.java
> Persistence unit -> CustomerJpaController.java

I'll have to run NetBeans tonight to remind myself of what it produces
as a "JPA controller". :-) Bear in mind, persistence units are actually
what are described in persistence.xml (one or more).

> Then I used these two classes to fill a JComboBox model, as shown here:
> 
> <http://stackoverflow.com/a/2531942/230513>
> 
> The example was easy to create, and I can see several things:
> 
> 1. The queries, getters, setters and annotations generated in the entity.
> 
> 2. The findCustomerXxx, create, edit and destroy methods generated in 
> the controller, which appear to correspond roughly to select, insert, 
> update and delete.
> 
Don't get me wrong, I'm a JPA enthusiast. Before it showed up I used the
native APIs in Toplink, Toplink Essentials and Hibernate, and even those
usually would win out over straight JDBC.

But what you did above just scratches the surface. It's now your
responsibility to read and understand the JPA specification and get the
lay of the land for the APIs. I mean "your" in the general sense here.

You've always used JDBC, you say. You're aware then that you have to
know quite a lot to use that well. You need to know a lot more - *plus*
understanding JDBC, IMO - to use JPA well. We've been throwing around
terms like conceptual or architectural weight - with JPA you pull in a
fair bit of that.

I don't believe that *you* would stop here - in fact you'd go ahead and
read the spec - but I've seen a fair few programmers that think that's
mostly all there is to JPA: use the IDE to generate from the DB, or vice
versa. They always run into problems sooner or later.

AHS
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

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

#14163

In article <u78or.34999$Ex1.4127@newsfe18.iad>,
 Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:

> On 12-05-02 12:37 AM, John B. Matthews wrote:
> > In article <jnn1pc$33c$1@dont-email.me>, markspace <-@.> wrote:
> > 
> >> And: is there a better, light-weight non-ORM package that you 
> >> might recommend instead?  Something a bit more complete.
> > 
> > Having always used JDBC, I wanted to see what a persistence unit 
> > looked like. I used the "New Entity Classes from Database Wizard" 
> > in NetBeans to generate an entity for a database table named 
> > CUSTOMER and clicked the persistence unit button to generate a JPA 
> > controller.
> > 
> > Entity -> Customer.java
> > Persistence unit -> CustomerJpaController.java
> 
> I'll have to run NetBeans tonight to remind myself of what it 
> produces as a "JPA controller". :-) Bear in mind, persistence units 
> are actually what are described in persistence.xml (one or more).

D'oh, I misinterpreted the results of my little experiment. Both 
Customer.java and CustomerJpaController.java are generated by the 
wizard; the Create Persistence Unit button generates the persistence.xml 
file from entries in a dialog. Opening the latter in the IDE is 
something akin to opening a .form file in the GUI designer.
 
> > Then I used these two classes to fill a JComboBox model, as shown 
> > here:
> > 
> > <http://stackoverflow.com/a/2531942/230513>
> > 
> > The example was easy to create, and I can see several things:
> > 
> > 1. The queries, getters, setters and annotations generated in the 
> > entity.
> > 
> > 2. The findCustomerXxx, create, edit and destroy methods generated 
> > in the controller, which appear to correspond roughly to select, 
> > insert, update and delete.
> > 
> Don't get me wrong, I'm a JPA enthusiast. Before it showed up I used 
> the native APIs in Toplink, Toplink Essentials and Hibernate, and 
> even those usually would win out over straight JDBC.
> 
> But what you did above just scratches the surface. It's now your 
> responsibility to read and understand the JPA specification and get 
> the lay of the land for the APIs. I mean "your" in the general sense 
> here.

Thanks for putting this in perspective. I'm a complete tyro to JPA, and 
I couldn't resist a little immediate gratification.

> You've always used JDBC, you say. You're aware then that you have to 
> know quite a lot to use that well. You need to know a lot more - 
> *plus* understanding JDBC, IMO - to use JPA well. We've been throwing 
> around terms like conceptual or architectural weight - with JPA you 
> pull in a fair bit of that.
> 
> I don't believe that *you* would stop here - in fact you'd go ahead 
> and read the spec - but I've seen a fair few programmers that think 
> that's mostly all there is to JPA: use the IDE to generate from the 
> DB, or vice versa. They always run into problems sooner or later.

By way of analogy, I see something similar with people thinking that a 
GUI designer will obviate the need to understand Swing.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

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

#14126

markspace schrieb:
> And: is there a better, light-weight non-ORM package that you might
> recommend instead? Something a bit more complete.

The example that you have posted involves a lot of classes.
You can build a framework that exposes only one class
XXXBean per table XXX, and that features bulk update,
delete and select, which you usually don't get via ORM,
or where you usually bypass the ORM.

The idea is as follows:
   - bulk update: Objects are not loaded, bean is just
       a facade to an SQL updates statement. No DB
       client roundtrips.
   - bulk delete: Objects are not loaded, bean is just
       a facade to an SQL delete statement. No DB
       client roundtrips.
   - bulk select: Only one object is loaded at a time,
       but the same object holder is reused, bean is
       just a facade to a SQL select statement and a
       cursor.

The idea shares the same benefits with an ORM:
   - possibility to have application specific column
     names and types.
   - transparent dealing with SQL dialects, i.e.
     issues such as boolean representation, string
     encoding etc...
   - Since colums correspond to methods, its easy
     to find usages in your application, i.e. cross
     referencing
   - Since columns correspond to methods, and these
     have types, it is easy to find compilation erros,
     i.e. wrong type use of columns etc..

So how will the API of such a XXXBean look like. Well
it will have the following methods:

   whereYYY(TTT);   Establish condition on column YYY
   calcYYY(TTT);    Establish value on column YYY
   TTT getYYY();    Retrieve value of column YYY
   list();          Open cursor
   next();          Advance cursor
   close();         Close cursor
   update();        Bulk update
   insert();        Single insert
   delete();        Bulk delete

For CRUD the API is used as follows:

                    C      R      U     D
   whereYYY(TTT);   -      x      x     x
   calcYYY(TTT);    x      -      x     -
   getYYY();        -      x      -     -
   list();          -      x      -     -
   next();          -      x      -     -
   close();         -      x      -     -
   update();        -      -      x     -
   insert();        x      -      -     -
   delete();        -      -      -     x

The framework can be extended to allow for column sorting,
aggregate functions, complex value expressions, complex
conditions, transactions, select caching, insert buffering,
etc.. The framework is not per se target towards proving
joins over tables. But it can be also enhanced in this
direction, even with distributed transactions.

Concerning joins, the participant XXXBeans need not come
from the same database. Deployment descriptions can define
the JDBC connection for individual XXXBeans. Here is how one
might copy from one table AAA column CCC to another table BBB
columnd DDD, where the two tables need not reside on the
same database.

   AAABean ab=new AAABean();
   ab.list();
   BBBBean bb=new BBBBean();
   while (ab.next()) {
     bb.calcDDD(ab.getCCC());
     bb.insert();
   }
   ab.close();

I am currently using such a framework called Matula. A very
old version which had ORM in mind is public (*). But now
its not classical ORM. Current drawback: Does not provide
delayed optimistic transactions as in Hybernate, since there
is no local object store.

Bye

(*)
http://www.xlog.ch/matula/

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

#14137

On 5/2/2012 3:22 AM, Jan Burse wrote:
> markspace schrieb:
>> And: is there a better, light-weight non-ORM package that you might
>> recommend instead? Something a bit more complete.
>
> The example that you have posted involves a lot of classes.


Really?  Two classes is a lot?  I'm not being sarcastic here, I don't 
understand how this is a lot.  I used QueryRunner and BeanHandler, that 
seems pretty pithy to me.


> You can build a framework that exposes only one class


While mucking about with the reflection API is fun, the goal is to avoid 
building my own framework. ;)


> http://www.xlog.ch/matula/


Ah ha!  Thanks, I'll check that out.

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

#14145

markspace schrieb:
> While mucking about with the reflection API is fun, the goal is to avoid
> building my own framework. ;)

*NO* reflection API was used at all, *NO* injection
pattern was used, also no penguins where harmed. The
framework consists of what would one call XDoclet today.

But instead of XDoclet I use JSP to generate via
its output the Java code for the XXXBeans. The
input are some property files and the JDBC access
to the meta data of the already existing DB.

+--------+     +-------------+
|   DB   |     | .properties |
+--------+     +-------------+
     |                |
     ------      -----
          |      |
          v      v
         +--------+
         |  JSP   |
         +--------+
              |
              v
        +------------+
        |  XXXBean   |
        +------------+

Some part of the framework deals with invoking JSP
without browser attention in kind of batch mode. But
using JSP to generate Java code is straight forward.
Check out genbean.jsp, it starts with:

public class <%=table%>Bean extends util.bean.BeanUtil {
   private util.bean.ColumnDescriptor[] columndescriptors;

And as you might expect it can generate Java code and
place what table has a value in front of Bean. Or something
more elaborate:

<%
   generator.bean.Column col=new generator.bean.Column();
   col.setTable(tab);
   col.list();
   while (col.next()) {
%>  private <%=col.getType()%> <%=col.getName()%>=<%=col.getNullConst()%>;
<%
   }
   col.close();
%>

The above iterates through the columns of the given table,
and the generates variable declarations.

Bye

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

#14152

Jan Burse wrote:
> *NO* reflection API was used at all, *NO* injection
> pattern was used, also no penguins where harmed. The
> framework consists of what would one call XDoclet today.
> 
> But instead of XDoclet I use JSP to generate via
> its output the Java code for the XXXBeans. The
> input are some property files and the JDBC access
> to the meta data of the already existing DB.
> 
> +--------+     +-------------+
> |   DB   |     | .properties |
> +--------+     +-------------+
>      |                |
>      ------      -----
>           |      |
>           v      v
>          +--------+
>          |  JSP   |
>          +--------+
>               |
>               v
>         +------------+
>         |  XXXBean   |
>         +------------+
> 
> Some part of the framework deals with invoking JSP
> without browser attention in kind of batch mode. But
> using JSP to generate Java code is straight forward.
> Check out genbean.jsp, it starts with:
> 
> public class <%=table%>Bean extends util.bean.BeanUtil {
>    private util.bean.ColumnDescriptor[] columndescriptors;
> 
> And as you might expect it can generate Java code and
> place what table has a value in front of Bean. Or something
> more elaborate:
> 
> <%
>    generator.bean.Column col=new generator.bean.Column();
>    col.setTable(tab);
>    col.list();
>    while (col.next()) {
> %>  private <%=col.getType()%> <%=col.getName()%>=<%=col.getNullConst()%>;
> <%
>    }
>    col.close();
> %>
> 
> The above iterates through the columns of the given table,
> and the generates variable declarations.

Scriptlet in JSP is an antipattern.

-- 
Lew

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

#14157

On 12-05-02 06:22 PM, Lew wrote:
> Jan Burse wrote:
[ SNIP ]

>> And as you might expect it can generate Java code and
>> place what table has a value in front of Bean. Or something
>> more elaborate:
>>
>> <%
>>    generator.bean.Column col=new generator.bean.Column();
>>    col.setTable(tab);
>>    col.list();
>>    while (col.next()) {
>> %>  private <%=col.getType()%> <%=col.getName()%>=<%=col.getNullConst()%>;
>> <%
>>    }
>>    col.close();
>> %>
>>
>> The above iterates through the columns of the given table,
>> and the generates variable declarations.
> 
> Scriptlet in JSP is an antipattern.
> 
You calling this an anti-pattern motivated me to go and see what
Wikipedia had to say about anti-patterns:
http://en.wikipedia.org/wiki/Anti-pattern. And as far as programming
anti-patterns go,
http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns.

What's rich is that at the beginning of the article they hand out some
rules for what differentiates anti-patterns from bad habits, bad
practices or bad ideas. Then they trot out a plethora of supposed
anti-patterns that completely violate their own definition.

I don't know when we passed into the zone of inanity with this entire
patterns business, but it couldn't have been more than a year or two
after GOF came out.

No reflection on the intent of your observation, Lew: scriptlets in JSPs
are generally a bad idea.

AHS
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

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

#14158

Lew schrieb:
> Scriptlet in JSP is an antipattern.

No,
Java EE 6 calls it even "deprecated".

But advantage of JSP is that it is readily
available. And its actually very old, already
around 1990. But you will not hear some praise
of it from me.

It has more been a conceptual issue in
matula how to generate XXXBean. But you
can  of course plug-in your preffered
template language in the below flow:

+--------+     +-------------+
|   DB   |     | .properties |
+--------+     +-------------+
     |                |
     ------      -----
          |      |
          v      v
         +--------+
         |>>Here<<|
         +--------+
              |
              v
        +------------+
        |  XXXBean   |
        +------------+

Now I am waiting for a post that says
.properties files are an anti pattern.
Which I can also agree upon. So the
point of the .properties files here is
to provide annotation of the DB schema.

Of course one can also use here anything
else than .properties files that allows
for peristence or input of some
annotations. So the flow is basically
as follows:

+--------+     +-------------+
|   DB   |     | >> Here 2 <<|
+--------+     +-------------+
     |                |
     ------      -----
          |      |
          v      v
        +-----------+
        |>>Here 1 <<|
        +-----------+
              |
              v
        +------------+
        |  XXXBean   |
        +------------+

Bye

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

#14159

Jan Burse schrieb:
> It has more been a conceptual issue in
> matula how to generate XXXBean. But you
> can  of course plug-in your preffered
> template language in the below flow:
>
> +--------+     +-------------+
> |   DB   |     | .properties |
> +--------+     +-------------+
>      |                |
>      ------      -----
>           |      |
>           v      v
>          +--------+
>          |>>Here<<|
>          +--------+
>               |
>               v
>         +------------+
>         |  XXXBean   |
>         +------------+

Advantage of using a template processor
where templates show the output generation
of the XXXBean basically as Java code with
holes in it, is the easy prototyping of
the templates.

Just take some code you have already written,
and that worked. And then generalize it by
making the holes into it and write code
around it that fills the holes.

Other less textual approaches would include
generating an AST, which is then textualized.
Generating an AST can be of one more advantage
than the template approach, since it would allow
non linear generation of the output. And one
could also use updates as part of the AST generation.

Templates with linearly interwined code are best
suited for code generation when the code generation
also follows some linear flow. So when the output
resembles a regular or context free grammar.
Something along these lines.

Bye

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

#14162

Jan Burse schrieb:
>
> But advantage of JSP is that it is readily
> available. And its actually very old, already
> around 1990. But you will not hear some praise
> of it from me.

A more profane reason not to use JSP is the
fact that it polutes the perm spaces of Java.
One JSP is compiled into a class, and you can
even recompile without stopping/starting a
web context. This is a realy nice feature.

But Java perm spaces can be restricted, and so
it can be prohibitive to use JSP when you
have a great number of templates. This is
not so much a problem when you only need
a couple of templates to generate some DB
beans and other associate Java classes.

But it can be a problem in many other circum-
stances. So one can then lookup one of the
many template languages and processors on
the market, or one can roll an own template
language and processor (*).

Bye

(*)
http://www.jekejeke.ch/idatab/doclet/blog/en/docs/int/jan/098_2011/096_template_proc/package.html

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

#14204

On 5/2/2012 6:27 PM, Jan Burse wrote:
> Jan Burse schrieb:
>> But advantage of JSP is that it is readily
>> available. And its actually very old, already
>> around 1990. But you will not hear some praise
>> of it from me.
>
> A more profane reason not to use JSP is the
> fact that it polutes the perm spaces of Java.
> One JSP is compiled into a class, and you can
> even recompile without stopping/starting a
> web context. This is a realy nice feature.
>
> But Java perm spaces can be restricted, and so
> it can be prohibitive to use JSP when you
> have a great number of templates. This is
> not so much a problem when you only need
> a couple of templates to generate some DB
> beans and other associate Java classes.
>
> But it can be a problem in many other circum-
> stances. So one can then lookup one of the
> many template languages and processors on
> the market, or one can roll an own template
> language and processor (*).

Java classes generated from JSP's are no
different than any other classes.

If you generate a class per something, then you
use perm gen space.

And the the classes are unloaded (via GC of
classloader) then the space is released again.

Arne

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

#14165

On 5/2/2012 6:03 PM, Jan Burse wrote:
> Lew schrieb:
>> Scriptlet in JSP is an antipattern.
>
> No,
> Java EE 6 calls it even "deprecated".

Really?

Where does it specify that?

> But advantage of JSP is that it is readily
> available. And its actually very old, already
> around 1990. But you will not hear some praise
> of it from me.

Java is from 1995 and JSP from 1999.

Arne

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web