Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: markspace <-@.> Newsgroups: comp.lang.java.programmer Subject: Re: Apache JDBC utils Date: Mon, 30 Apr 2012 19:27:24 -0700 Organization: A noiseless patient Spider Lines: 63 Message-ID: References: <3265763.6.1335834184189.JavaMail.geo-discussion-forums@pbph1> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 1 May 2012 02:27:27 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="7zTeebvKpIS8LVJ5OFDmwg"; logging-data="20898"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5FY9j3I9Q/u9I3+7TJPlNL9GMFKPtrWA=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 In-Reply-To: <3265763.6.1335834184189.JavaMail.geo-discussion-forums@pbph1> Cancel-Lock: sha1:qyqhCsSfveSXpz+Z6dfgw58dR2Q= Xref: csiph.com comp.lang.java.programmer:14068 On 4/30/2012 6:03 PM, Lew wrote: > > That's funny. You say, "No ORM", then immediately describe the ORM > library you're using. ... > How is the one you're using not ORM? Well, I'll point out the main landing page for the project specifically says that dbutils is not an ORM. "DbUtils is not: An Object/Relational bridge - there are plenty of good O/R tools already. DbUtils is for developers looking to use JDBC without all the mundane pieces." If the authors of the projects say it's not ORM, I'll choose to believe them. > The idiom that won for me was non-monolithic JPA (as opposed to the > monolithic idiom I've seen in most shops and was the root of their > complaints about JPA). Could you describe what you mean by "non-monolithic" vs "monolithic?" I don't think I've heard those terms before and I'd be interested to see what you are referring too. As for "I've done this exercise myself, repeatedly" yeah I seem to be going down the same road. Building small prototypes to see how the result actually functions. In general I think doing is the best way to learn, so I don't mind doing some extra work in order to get some learnin'. > It is very light weight, for how I use the term "light weight". > > How do you mean the term, precisely? I think I mean relatively speaking. Something is lighter weight in comparison to certain alternates. Lighter weight in terms of options, configuration required or configuration options, lighter weight in terms of number features needed to learn, lighter weight in terms of API calls needed to be conversant with before one can be productive. > I prefer EclipseLink and OpenJPA, myself. They go so far as to > abstract away even that pseudo-SQL, for the common case. You write > some annotations and Bob's your uncle. I'm somewhat conversant with JPA 2.0. I'm just looking at alternatives for a comparison. What, if any, advantages do other APIs provide? So far my personal jury is still out. Although I can see a customer for example specify specifying something other than JPA for their own reasons, and it might not (as in very probably not) be my place to second-guess their business decision. That I think would be the main reason, imo, to not use a full JPA solution.