hibernate-devel

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

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

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

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

hmmm, that was one thing I had been uncertain about. I always hated the
anonymous-looking "?" in JDBC. I had considered allowing "$1", "$2" etc
in Hibernate queries but this would have been harder to implement and
I decided to go for something that would be familiar to people who
only use JDBC.

We could still add support for $1, $2, etc if we wanted to. It might
even be worth the effort....

Implementing this would be a matter of replacing the $N with a ? and
then remapping parameter N to the sequential position of ?

Not really very hard to do.

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

yes, quite so.

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

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

Actually, stuff $1, $2, etc. One of the things we could do if we had
a Query interface would be to allow proper named identifiers. eg.

session.prepareQuery("from foo in class Foo where foo.name = $name");
q.setParameter("name", fooName, Hibernate.STRING);
q.setMaxResultSize(50);
List results = q.getResultList();

Thats really nice, I think....

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