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

[Anton v. S. <an...@ap...>]

> Yes, absolutely. I still don't think it is completely misguided to
> have the find() and iterate() methods there on the Session

I agree, I wasn't dissing Session ;)  I do see Session as being a useful
aggregation of related functionality.  But using Session as a gateway to
more sophisticed services makes a lot of sense, and will keep Session from
bloating and becoming unmanageable.  In fact, I had argued for putting e.g.
a commitTransaction() method on Session, but I now think you were correct in
nixing that.  The right balance is subjective, of course.

> I think it makes perfect sense to support both, personally....

Sure.  I was really saying that I think the API form is probably easier to
implement, opens up some other possibilities, and reduces the need for the
language form, so the API should be the higher priority.

> 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.

In general, I'm completely in favor of anything that reduces the amount of
code, and expresses something at a higher semantic level, which query
languages usually do (or there'd be no point to them).  But I think one
problem with embedding query strings is that languages like Java aren't very
well suited to it, in the absence of some kind of preprocessing (like SQLJ
or JSQL).  Not supporting multi-line strings, and having unnamed
placeholders like "?" which are then dependent on sequence to match up with
external parameters, doesn't help matters.

> 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.....

The argument I see is that restricting the number of records returned is not
very closely connected semantically to other things expressed in a query,
which primarily relate to the content of the data being queried.  Adding
something like this to the query language might be a convenience, but it
doesn't meaningfully affect the expressivity of the query language.  From
there, one could argue about keeping custom languages simple and focused, or
something... :)

I'd have to reverse that conclusion if the language feature became capable
of more than simply limiting the total number of returned objects.  For
example, given GROUP BY functionality, if you could say something like
"select first 4 Persons from...group by company", and get a result set
containing the first 4 objects in each grouping, that would add expressivity
to the query language.  The fact that it could also be used to limit the
number of objects returned in a simple ungrouped query would merely be a
convenient side effect.

Anton