New release candidate build

[Hannes Wallnoefer]

Hi all,

I just uploaded a new release candidate build for Helma 1.7.0.

http://adele.helma.org/download/helma/1.7.0-rc3/

As announced earlier, this is the first one to come with a bundled
version of HelmaSwarm. Another novelty are the debian packages. there
are three debs for the main Helma installation, the API docs, and
HelmaSwarm.

http://adele.helma.org/download/helma/1.7.0-rc3/debian/

Please let me know how it's working.

Hannes

[Hannes Wallnoefer]

Well, obviously there were some problems with rc3.

http://dev.helma.org/trac/helma/log/?action=stop_on_copy&rev=9904&stop_rev=9880&mode=stop_on_copy

The biggest change I made was that I moved the test suite into the
modules directory, added a few tests and started running them on
PostgreSQL and Oracle in addition to MySQL.

I'm very happy with the result. I fixed a few small and not so small O/
R bugs along the way.

So, before I release a new (and final, I think) release candidate
please give svn trunk some testing, and let me know how it goes.

Hannes

[Maksim Lin]

Hi Hannes,
I think there was still a bug in the rc in the goupby part of the or
code. I have'ntt filed a bug report yet since I had not had the time
to write a isolated test case.
I'll grab trunk from svn and see if I can still reproduce the problem.

Thanks,
Maks

[Maks]

Hi again,

I did some more testing and it turns out that the error I was seeing
in one of my apps is actually due to H2's restrictions on using "group
by" along with "order by" as the sql generated by Helma gives an
exception:

Caused by: org.h2.jdbc.JdbcSQLException: Column START_TIME must be in
the GROUP
BY list; SQL statement:
SELECT EVENTS.START_DATE FROM EVENTS GROUP BY START_DATE ORDER BY
START_TIME [90016-109]

BUT the above works ok in MySQL.

The above sql is generated for properties config of:

events = collection(Event)
events.group = START_DATE
events.group.order = START_TIME
events.group.prototype = EventGroup

with the EventGroup prototype simply having a:
_children = collection(Event)

So this isn't a showstopper for the RC at all, but I thought I'd
report it here as I know others use H2+Helma combo.

thanks,
Maks.

[Hannes Wallnoefer]

On Sep 22, 8:47 am, Maks <maksim....@gmail.com> wrote:
> Hi again,
>
> I did some more testing and it turns out that the error I was seeing
> in one of my apps is actually due to H2's restrictions on using "group
> by" along with "order by" as the sql generated by Helma gives an
> exception:
>
> Caused by: org.h2.jdbc.JdbcSQLException: Column START_TIME must be in
> the GROUP
> BY list; SQL statement:
> SELECT EVENTS.START_DATE FROM EVENTS GROUP BY START_DATE ORDER BY
> START_TIME [90016-109]
>
> BUT the above works ok in MySQL.

Actually, this is not a special restriction in H2 but a bug in MySQL.
If you think about it, you can't order on a column you group by,
because which particular value from a group of rows should be used for
ordering?

Anyway, this is among the things I fixed since the last RC3. Helma now
uses SELECT DISTINCT which is much smarter anyway.

Hannes

[Maksim Lin]

> Actually, this is not a special restriction in H2 but a bug in MySQL.
> If you think about it, you can't order on a column you group by,
> because which particular value from a group of rows should be used for
> ordering?

Yes, very good point.

> Anyway, this is among the things I fixed since the last RC3. Helma now
> uses SELECT DISTINCT which is much smarter anyway.
>

Oops, you're quite right! I was using the wrong jar, so I was still
testing with an old RC2.
Unfortunately the current trunk seems to still not quite work with H2.
I've filed a bug to helpp track this properly:
http://dev.helma.org/bugs/show_bug.cgi?id=681

thanks,
Maks.

[Hannes Wallnoefer]

2009/9/23 Maksim Lin <maksi...@gmail.com>:

Well, the same thing applies here:

If you select distinct START_DATE then you have to sort by that
column, otherwise H2 does not know which particular value to use for
sorting a group of rows with the same START_DATE.

I would have thought that sorting by an aggregate function over
another column should work too, like use min(START_TIME) or
max(START_TIME) or to sort by the smallest or largest value of a
group. It doesn't work in MySQL, though (only returns one result).

Hannes

> thanks,
> Maks.
>
> >
>

[Simon Oberhammer]

Maksim Lin <maksim....@gmail.com> wrote:
> Caused by: org.h2.jdbc.JdbcSQLException: Column START_TIME must be in
> the GROUP
> BY list; SQL statement:
> SELECT EVENTS.START_DATE FROM EVENTS GROUP BY START_DATE ORDER BY
> START_TIME [90016-109]
>
> BUT the above works ok in MySQL.

I know mysl does something custom the other way around:

if you do a GROUP BY then it always, implictly does a ORDER BY for the
those columns if they are references in the output.

e.g. if you say "SELECT foo FROM bar GROUP BY foo" mysql rewrites that
too "SELECT foo FROM bar GROUP BY foo ORDER BY foo"

another special extension is that you *can* actually SELECT a column
that was not referenced at all in the GROUP BY - though the result of
that is not always what you would expect.

my sql is sometimes still broken from too msyql-exposure

- simon

[Hannes Wallnoefer]

2009/9/24 Simon Oberhammer <simon.ob...@gmail.com>:

>
> Maksim Lin <maksim....@gmail.com> wrote:
>> Caused by: org.h2.jdbc.JdbcSQLException: Column START_TIME must be in
>> the GROUP
>> BY list; SQL statement:
>> SELECT EVENTS.START_DATE FROM EVENTS GROUP BY START_DATE ORDER BY
>> START_TIME [90016-109]
>>
>> BUT the above works ok in MySQL.
>
> I know mysl does something custom the other way around:
>
> if you do a GROUP BY then it always, implictly does a ORDER BY for the
> those columns if they are references in the output.
>
> e.g. if you say "SELECT foo FROM bar GROUP BY foo" mysql rewrites that
> too "SELECT foo FROM bar GROUP BY foo ORDER BY foo"

And I even know the reason why: it uses an index over foo to create
the result set, and that index is sorted by foo, of course. I bet if
you don't have an index over foo, the result won't be sorted that way.

> another special extension is that you *can* actually SELECT a column
> that was not referenced at all in the GROUP BY - though the result of
> that is not always what you would expect.

I don't think I want to know what it is. What is it?

> my sql is sometimes still broken from too msyql-exposure

So is mine. It's high time MySQL gets nuked by Oracle (just kidding :)

Hannes

>  - simon
> >
>

[Maksim Lin]

So should I just update the doc for Type.properties to mention that
you cannot sort on a different column to the one you groupby?, as
currently it suggests the opposite.