RE: Patch for DISTINCT, ORDER BY issue

From: Scott Finnerty (scot..odefuey.com)
Date: Fri Oct 10 2003 - 21:02:33 EDT

  • Next message: Andrus Adamchik: "RE: Patch for DISTINCT, ORDER BY issue"

    I reworked the changes to SelectTranslator to ensure a unique column set.

    I looked and since I don't alter the "official" column list in
    SelectTranslator, and it creates the ResultDescriptor from that column list,
    the DefaultResultIterator should not be affected by these changes.

    Scott

    -----Original Message-----
    From: Scott Finnerty [mailto:scot..odefuey.com]
    Sent: Friday, October 10, 2003 1:23 PM
    To: cayenne-deve..bjectstyle.org
    Subject: RE: Patch for DISTINCT, ORDER BY issue

    I'll rework the change to ensure a unique column set - but you do understand
    that in order to comply with the database restrictions that the following
    will still likely occur: SELECT DISTINCT .... t0.NAME, ... UPPER(t0.NAME)
    ... ORDER BY UPPER(t0.NAME)? So some extra baggage is unavoidable in this
    instance (with the case insensitive order by) if we are to address the
    issue.

    I'll have a look at the DefaultResultIterator to see what effect my change
    may have had.

    Thanks,
    Scott

    -----Original Message-----
    From: Andrus Adamchik [mailto:andru..bjectstyle.org]
    Sent: Friday, October 10, 2003 12:56 PM
    To: cayenne-deve..bjectstyle.org
    Subject: Re: Patch for DISTINCT, ORDER BY issue

    On Friday, October 10, 2003, at 01:24 PM, Scott Finnerty wrote:

    >
    > The patch I have included will accumulate the expressions added by the
    > specified orderings and then if the DISTINCT modifier is used, it will
    > add
    > those expressions to the column list in the generated SQL. This seems
    > like
    > it should be harmless even to databases that don't require this. It
    > will,
    > in some cases, cause the same column expression to appear twice in the
    > generated query. I suppose a more sophisticated approach would be to
    > accumulate all of the column expressions to include in the select and
    > then
    > only generate a unique set so no expression is duplicated. If you
    > agree, I
    > could revise and resubmit.

    Will have a look at it when I have time during the weekend. I think
    having a unique column set is the desired solution. Since otherwise
    JDBC driver will be bringing lots of unneeded data back to the client.

    Also one thing to watch for (maybe you addressed this already, or maybe
    this is simply a non-issue..?) is that these extra columns do not end
    up in the snapshot read by DefaultResultIterator.

    > The patches are against the 10/9 nightly snapshot.
    >
    > It would be nice if these were also applied to the stable release as a
    > maintenance release.

    +1. If we have to put 1.0.1 on hold for another week because of that, I
    don't see a big deal.

    Andrus


    This archive was generated by hypermail 2.0.0 : Fri Oct 10 2003 - 21:02:36 EDT