Slides - Ebean Query Language Introduction

[Rob Bygrave]

In the Google Group Files, I have put up a Slide Presentation (pdf) ... as an "Introduction to Ebean's Query Language".

The source is an Open Office Impress presentation which I will put up as well.

I'd be really interested to get feedback on it. Whether it is useful or rubbish etc.


Thanks, Rob.

[Daryl Stultz]

On Mar 24, 6:47 am, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> I'd be really interested to get feedback on it. Whether it is useful or
> rubbish etc.

Hi Rob, definitely some good information here. Slide shows are for
presentation from a speaker and thus are a little hard to read myself,
but I think the info is quite useful. I do have a couple of picky
things. I'm big on good english/grammar, etc., so I'm going to pick on
you for this: "AKA" means "also known as". You seem to use it as "in
other words." Sorry, I hope we can still be friends. :-)

I think the choice of the terms "join fetch" for JPA and "join" for
ebean are unfortunate and don't lead to quick understanding for people
coming from SQL. I think "fetch" would be a better term, but I
understand the water is probably too far down stream for a change to
this.

Finally, one question: when I use filterMany() can I specify the
order?

Thanks.

/Daryl

[Rob Bygrave]

> "AKA" means "also known as".

Ha, I have been abusing poor old AKA for years... Good call, I'll look to change that.

> terms "join fetch" for JPA and "join" for ebean are unfortunate

You are right. I have a saying in my head that sometimes I verbalise - "It doesn't hurt to be bloody obvious". (excuse my language). Unfortunately it is becoming clear that "join" is not obvious.

Although there has been a fair bit of water etc... we could make "fetch" a synonym for "join" ... change the docs to reflect that and gradually people will change over. It is certainly possible. When I did those slides ... I had that "It doesn't hurt to be bloody obvious" feeling.  If I have to explain it ... it is surely not obvious enough.

"fetch" ... is much more obvious and clear as to the intent. I like it. Ebean will hopefully live for many years yet so imo such a change is well worth it.

> when I use filterMany() can I specify the order?

Currently no. That said, I don't see a reason why we shouldn't be able to do that. It intuitively makes sense to be able to do so and is a natural place for it.  It could just get appended to the 'parent/root' order by clause I would think.

To unsubscribe from this group, send email to ebean+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Daryl Stultz]

On Mar 24, 9:10 pm, Rob Bygrave <robin.bygr...@gmail.com> wrote:

> You are right. I have a saying in my head that sometimes I verbalise - *"It
> doesn't hurt to be bloody obvious"*. (excuse my language).

Ah, you are British, no? (Or shall I say "local"?) It seems like
"bloody" is a "class 1" swear, like the "F" word, but to us Americans
it sounds more like "dang". :-)

> Currently no. That said, I don't see a reason why we shouldn't be able to do
> that. It intuitively makes sense to be able to do so and is a natural place
> for it.  It could just get appended to the 'parent/root' order by clause I
> would think.

Seems so, yes. The trick is making it clear how to work it from a
fluid perspective. I tried this:

where()...
.eq(...)
.orderBy("thing1")
.filterMany("foo")
.orderBy("thing2")

It didn't work. :-)

> > On Mar 24, 6:47 am, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> > > I'd be really interested to get feedback on it. Whether it is useful or
> > > rubbish etc.

One more question. For this query:

find order
join customer (+lazy(10) name, status)
join customer.billingAddress
where...

and this comment:

Also load the customer's billingAddress when the
customer is loaded.

I don't really know what my question is. I guess it's not clear why
the billingAddress is is fetched upon lazy load of customer. Perhaps
the query is "building in layers" meaning the order makes a
difference? What would this do?

find order
join customer.billingAddress
join customer (+lazy(10) name, status)
where...

If the answer is "the same thing" maybe it's building dependency by
path?

/Daryl

[Rob Bygrave]

> Ah, you are British, no?

Nope. Kiwi (New Zealander)

> It didn't work. :-)

No, it won't work unless/until I change it. That is, the intention was that you could NOT add a orderBy to the filterMany ... so that is just 'proxing' through to the orderBy on the root.  So it would have to change to make it work... and it could get confusing with the fluid approach.

> it's building dependency by path?

Yes, it is by path.

So any path after "customer" ... would be included in the "customer" +lazy query.
NB: You can't actually get to the "customer.billingAddress" without going through "customer." first.

On Thu, Mar 25, 2010 at 2:32

 PM, Daryl Stultz <kungfum...@gmail.com> wrote:

/Daryl