Grails anybody?

[tomasz brymora <to...@yahoo.com>]

Greetings!
I just have a couple of quickie questions. 

Is anyone using iBatis with Grails?

Are there any plans in the works for an iBatis plugin
for Grails?

I've been working on project using Grails and as much
as I like the concept, it's integration with Hibernate
is pretty much a deal breaker for non-prototype dev.

thanks, T

Re: Grails anybody?

[Brandon Goodin <br...@gmail.com>]

We actually do have a gBatis project started offsite of apache (
http://gbatis.silvermindsoftware.com/). It is extremely preliminary. The
thought was to write a complete Groovy based implementation of iBATIS from
ground up. I've put the project on hold for the immediate until the iB3 API
comes out. With the way iB3 is being written it may be easier to integrate
iB3 with Groovy rather than write a ground up implementation.

The goals are pretty simple.

* provide a more robust means of executing sql - There is definitely room to
improve groovy sql with an ibatis approach to sql execution.
* provide a way to configure using builders
* provide a dynamic sql implementation

Brandon Goodin

On Tue, Apr 1, 2008 at 12:24 PM, Clinton Begin <cl...@gmail.com>
wrote:

> I'm going to be totally honest....
>
> If Java was Groovy, I never would have written iBATIS.  The database
> APIs (especially the integration with GString -- despite a few
> limitations) is the smartest thing I've ever seen in database API
> design.  Not only is it better than JDBC, it's better than Ruby's
> database APIs (not saying much). That combined with Groovy's support
> for multiline strings make it about 75% capable of doing what iBATIS
> does anyway.  iBATIS was really a framework originally designed to
> solve only two problems:
>
> * JDBC API verbosity
> * SQL looks like crap embedded in Java code (due to the lack of
> multiline strings and a decent string library)
>
> Groovy solves both of those quite well (perhaps iBATIS still has an
> edge). Later on we added...
>
> * Improved patterns for transaction management
> * A few bells and whilstles like caching, lazy loading, join mapping,
> etc...
>
> So that said, I suppose iBATIS could offer improvements in the area of
> transactions and the bells and whistles.
>
> But where would you see most of the value of a gBATIS (or whatever
> we'd call it)?  :-)
>
> Cheers,
> Clinton
>
> On Tue, Apr 1, 2008 at 9:46 AM, tomasz brymora <to...@yahoo.com>
> wrote:
> > Greetings!
> >  I just have a couple of quickie questions.
> >
> >  Is anyone using iBatis with Grails?
> >
> >  Are there any plans in the works for an iBatis plugin
> >  for Grails?
> >
> >  I've been working on project using Grails and as much
> >  as I like the concept, it's integration with Hibernate
> >  is pretty much a deal breaker for non-prototype dev.
> >
> >  thanks, T
> >
>

Re: Grails anybody?

[Clinton Begin <cl...@gmail.com>]

I'm going to be totally honest....

If Java was Groovy, I never would have written iBATIS.  The database
APIs (especially the integration with GString -- despite a few
limitations) is the smartest thing I've ever seen in database API
design.  Not only is it better than JDBC, it's better than Ruby's
database APIs (not saying much). That combined with Groovy's support
for multiline strings make it about 75% capable of doing what iBATIS
does anyway.  iBATIS was really a framework originally designed to
solve only two problems:

* JDBC API verbosity
* SQL looks like crap embedded in Java code (due to the lack of
multiline strings and a decent string library)

Groovy solves both of those quite well (perhaps iBATIS still has an
edge). Later on we added...

* Improved patterns for transaction management
* A few bells and whilstles like caching, lazy loading, join mapping, etc...

So that said, I suppose iBATIS could offer improvements in the area of
transactions and the bells and whistles.

But where would you see most of the value of a gBATIS (or whatever
we'd call it)?  :-)

Cheers,
Clinton

On Tue, Apr 1, 2008 at 9:46 AM, tomasz brymora <to...@yahoo.com> wrote:
> Greetings!
>  I just have a couple of quickie questions.
>
>  Is anyone using iBatis with Grails?
>
>  Are there any plans in the works for an iBatis plugin
>  for Grails?
>
>  I've been working on project using Grails and as much
>  as I like the concept, it's integration with Hibernate
>  is pretty much a deal breaker for non-prototype dev.
>
>  thanks, T
>

Re: Grails anybody?

[Darren Davison <da...@davisononline.org>]

On Tue, Apr 01, 2008 at 08:46:55AM -0700, tomasz brymora wrote:
> Is anyone using iBatis with Grails?

I'm not, but I do use both grails and iBATIS a lot on different
projects.

There should be no reason not to.  Since pre-1.0 of grails, they removed
the tight coupling to hibernate and you can now simply take hibernate
out of the equation for any grails project by removing the hibernate
plugin.

Unfortunately I can't speak intelligently about how you plugin another
persistence mechanism since I've never tried it.  Suggest you ask on the
grails mailing list, which is high volume but pretty responsive too.

I think your post does raise an interesting point about grails though
(to wander slightly, but not entirely OT).  I can't help thinking the
dev team has missed a bit of a trick here.  Grails is a superb
framework, but surely it's sweet spot has got to be providing web
front-ends, with all the great plugins and ajaxy stuff it makes so easy,
but against legacy middle- and/or back-end tiers that already exist or
will be written in Java.  I know they'll tell me you *can* do this, but
IMHO they should push it harder - seems a more likely path to the
enterprise than pushing the full-stack green-field capabilities of the
framework.

Just my $0.02

-- 
Darren Davison
Public Key: 0xE855B3EA