RE: [Hibernate-devel] New feature discussion (max query result list size)

[Gavin_King/Cirrus%<CI...@ci...>]

> I don't think it's a bad thing to start "breaking down" the Session
> interface like this, for the reasons you say:

>> On the _very_ positive side it allows easy and elegant extension
>> to setting other things like fetch sizes. Incidently, this is
>> the standard model used by persistence layers.

>...which arises from general good design principles, e.g. small
>special-purposes interfaces being generally better and more cleanly
>extensible than large general-purpose interfaces.

Yes, absolutely. I still don't think it is completely misguided to
have the find() and iterate() methods there on the Session, for
convenience. My thinking on this (much) earlier on was that

list = s.find("from foo in class bar.Foo where foo.name=?", "foo",
Hibernate.STRING);

is more compact than:

Query q = s.prepareQuery("from foo in class bar.Foo where foo.name=?");
q.setParameter(1, "foo", Hibernate.STRING);
list = q.execute();
q.close();

But certainly the second form is more flexible and arguably more elegant.
I think it makes perfect sense to support both, personally....

>However, Hibernate is a little different in that it assumes that its
clients
>are always Java code, whereas these other query languages have to deal
with
>being called from all sorts of clients, and can't easily expose a
consistent
>object API to all its possible clients.  Hibernate doesn't have that
>restriction, so it's less important to have a feature like this in the
query
>language itself.

I think theres an interesting issue here in that while certain things are
more directly and elegantly expressible in Java, others are much easier to
express in a query language. I have a problem with some persistence
solutions that reject the idea of embedding query strings in application
code and try to construct a query through manipulation of objects.
Usually this code is quite unreadable and logwinded.

I think this particular problem is a borderline case. There is a strong
argument somewhere that borderline cases should be done in Java code for
the sake of compile-time syntax checking, self-documentation, etc.....