Fluent SelectBuilder

[Josh Stone <pa...@gmail.com>]

Hi,

I'm new to iBatis, currently assessing the features for an upcoming project,
and I came across one feature that struck me as being odd - the
SelectBuilder. I'm not sure if this is what was intended as the
implementation of the "dynamic SQL API" described on the 3.0 whiteboard, but
I was wondering if there's a reason why the SelectBuilder API isn't a true
fluent builder API as opposed to the loosely coordinated ThreadLocal backed
implementation? I'm sure that a fluent query API with support for
conditional logic would be a challenge, but there as there are several good
fluent query APIs in various frameworks I would have expected to see
something similar here. This is not a criticism, I'm just wondering if there
was some reason why the API is not fluent.

Cheers,
Josh

Re: Fluent SelectBuilder

[Josh Stone <pa...@gmail.com>]

Thanks for the response. I or one of my colleagues may indeed have some
feedback or some contributions to offer in this area. We'll follow up later
when we do.

Cheers,
Josh

On Mon, Mar 22, 2010 at 4:42 PM, Clinton Begin <cl...@gmail.com>wrote:

> Criticism is welcome here, especially in this somewhat "risky" feature.
>
> To begin though, SelectBuilder is more of a utility than anything.  You
> could easily create your own builder and use it with no consequence.  There
> is no dependency on SelectBuilder nor any requirement to use it.
>
> My story is that I started building SelectBuilder as a more normal builder
> style pattern.  But I found it to be very verbose and awkward to use.  I
> looked around online to see what others had done, and my first observation
> was that there weren't many out there.  If memory serves, Hibernate does a
> pretty good job with its query by example, but it can leverage the object
> oriented nature of its mappings, and eliminate the verbosity and complexity
> of joins etc.
>
> Some of the most influential APIs that I found came from other languages
> like Groovy and Ruby.  While I couldn't build a perfect DSL due to the lack
> of closures, I figured that perhaps an 80/20 API that allowed for most
> simple SQL statements to be built conditionally, would work well enough.
>
> So I created the SelectBuilder API as you see it today.  The goal was to
> create an embedded language extension of sorts, that read simpler and almost
> like SQL, rather than Java code.  The key feature it offers is the ability
> to nest it between conditionals and loops without having to manage string
> concatenation or brackets etc.
>
> It is a risk.  I've had very little feedback on it, probably because most
> people still lean toward the XML for dynamic SQL (especially given the much
> nicer dynamic SQL query elements).
>
> Give it a shot, and feel free to offer comments and suggestions.
>
> Cheers,
> Clinton
>
>
>
>
> On Mon, Mar 22, 2010 at 5:02 PM, Josh Stone <pa...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm new to iBatis, currently assessing the features for an upcoming
>> project, and I came across one feature that struck me as being odd - the
>> SelectBuilder. I'm not sure if this is what was intended as the
>> implementation of the "dynamic SQL API" described on the 3.0 whiteboard, but
>> I was wondering if there's a reason why the SelectBuilder API isn't a true
>> fluent builder API as opposed to the loosely coordinated ThreadLocal backed
>> implementation? I'm sure that a fluent query API with support for
>> conditional logic would be a challenge, but there as there are several good
>> fluent query APIs in various frameworks I would have expected to see
>> something similar here. This is not a criticism, I'm just wondering if there
>> was some reason why the API is not fluent.
>>
>> Cheers,
>> Josh
>
>
>

Re: Fluent SelectBuilder

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

Criticism is welcome here, especially in this somewhat "risky" feature.

To begin though, SelectBuilder is more of a utility than anything.  You
could easily create your own builder and use it with no consequence.  There
is no dependency on SelectBuilder nor any requirement to use it.

My story is that I started building SelectBuilder as a more normal builder
style pattern.  But I found it to be very verbose and awkward to use.  I
looked around online to see what others had done, and my first observation
was that there weren't many out there.  If memory serves, Hibernate does a
pretty good job with its query by example, but it can leverage the object
oriented nature of its mappings, and eliminate the verbosity and complexity
of joins etc.

Some of the most influential APIs that I found came from other languages
like Groovy and Ruby.  While I couldn't build a perfect DSL due to the lack
of closures, I figured that perhaps an 80/20 API that allowed for most
simple SQL statements to be built conditionally, would work well enough.

So I created the SelectBuilder API as you see it today.  The goal was to
create an embedded language extension of sorts, that read simpler and almost
like SQL, rather than Java code.  The key feature it offers is the ability
to nest it between conditionals and loops without having to manage string
concatenation or brackets etc.

It is a risk.  I've had very little feedback on it, probably because most
people still lean toward the XML for dynamic SQL (especially given the much
nicer dynamic SQL query elements).

Give it a shot, and feel free to offer comments and suggestions.

Cheers,
Clinton




On Mon, Mar 22, 2010 at 5:02 PM, Josh Stone <pa...@gmail.com> wrote:

> Hi,
>
> I'm new to iBatis, currently assessing the features for an upcoming
> project, and I came across one feature that struck me as being odd - the
> SelectBuilder. I'm not sure if this is what was intended as the
> implementation of the "dynamic SQL API" described on the 3.0 whiteboard, but
> I was wondering if there's a reason why the SelectBuilder API isn't a true
> fluent builder API as opposed to the loosely coordinated ThreadLocal backed
> implementation? I'm sure that a fluent query API with support for
> conditional logic would be a challenge, but there as there are several good
> fluent query APIs in various frameworks I would have expected to see
> something similar here. This is not a criticism, I'm just wondering if there
> was some reason why the API is not fluent.
>
> Cheers,
> Josh