<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Alexander Kozlovsky wrote:<br>
    </div>
    <blockquote
cite="mid:CAGM6z1tt_+Fpii7ZMEUs4eKPA5Y6EapZhPR+SX_qDfLe+4QR-w@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi, Tomislav!<br>
      </div>
    </blockquote>
    Hello!<br>
    Thanks for the quick response.<br>
    <blockquote
cite="mid:CAGM6z1tt_+Fpii7ZMEUs4eKPA5Y6EapZhPR+SX_qDfLe+4QR-w@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        In your first example<br>
        <br>
        <div>    q = select(<a moz-do-not-send="true"
            href="http://p.name">p.name</a> for p in Person)</div>
        <div>    q = q.filter(lambda p: p.age > 30)</div>
        <div><br>
        </div>
        <div>The filter didn't work, because the argument "p" used in
          lambda refers to the entire result of the first query, that </div>
      </div>
    </blockquote>
    Yes, I know. I just put it as an example of what I'm trying to
    accomplish.<br>
    <blockquote
cite="mid:CAGM6z1tt_+Fpii7ZMEUs4eKPA5Y6EapZhPR+SX_qDfLe+4QR-w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>To fix this, we should refer to the iterator names of the
          original select. It is possible if we write lambda without
          arguments as in the following example:</div>
        <div><br>
        </div>
        <div>
          <div>    q = select(<a moz-do-not-send="true"
              href="http://p.name">p.name</a> for p in Person)</div>
          <div>    q = q.filter(lambda: p.age > 30)</div>
        </div>
        <div><br>
        </div>
        <div>When lambda doesn't receive any arguments, it refers to the
          names used in the original select, so it is possible to refine
          query with any filtering criteria.</div>
      </div>
    </blockquote>
    This is great! I didn't know this was possible! You should put more
    examples and/or documentation describing these finer features. <br>
    <blockquote
cite="mid:CAGM6z1tt_+Fpii7ZMEUs4eKPA5Y6EapZhPR+SX_qDfLe+4QR-w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
          As per the second example:</div>
        <div><br>
        </div>
        <div>    q2 = select(<a moz-do-not-send="true"
            href="http://p.name">p.name</a> for p in q1)</div>
        <div><br>
          Pony doesn't support such queries right now, but we plan to
          add them later.<br>
        </div>
      </div>
    </blockquote>
    That would be excellent.<br>
    <blockquote
cite="mid:CAGM6z1tt_+Fpii7ZMEUs4eKPA5Y6EapZhPR+SX_qDfLe+4QR-w@mail.gmail.com"
      type="cite">
      <div dir="ltr">We can add a way to specify projection, but at
        first we should understand what is the right API to do such
        projection. There are two options:<br>
        <div><br>
          1) A programmer can specify the desired attributes when they
          write a query. In this case a query returns entity objects,
          but internally they contains specified attributes only. Other
          attributes behave as if they are lazy - their values will be
          loaded by a separate query if you'll try to access them.<br>
          <br>
          2) Another option would be to have the map() query method
          which can transform query result:</div>
        <div><br>
        </div>
        <div>In this case, you don't receive partially-loaded object
          from the query, but instead you get attribute values. This way
          only the specified attributes will be loaded from the
          database.<br>
          <br>
          What do you think, which API option solves your task better?<br>
        </div>
      </div>
    </blockquote>
    As I said, I'm just exploring the possibilities, so I don't have a
    concrete task at the moment. The thing about dropdown lists and
    datagrids was an example (but, based on some previous projects).<br>
    Personally, I'd prefer API option 2. The 1. option seems a bit too
    magical :) But I don't see a difference between the result of the
    API 2 and the planned feature:<br>
    q2 = select(<a href="http://p.name">p.name</a> for p in q1)<br>
    As I see it, both of them would eventually give me a tuple with the
    selected attribute values, with (perhaps) the additional possibility
    of further filtering and/or projecting q2 :)<br>
    However, being a long time C# and Linq developer, the planned
    feature seems the most 'natural' to me, so this would be fine when
    it comes out.<br>
    So, in a nutshell:<br>
    1. planned feature<br>
    2. API 2<br>
    3. API 1<br>
    <br>
    Thanks, <br>
    Tom<br>
    <blockquote
cite="mid:CAGM6z1tt_+Fpii7ZMEUs4eKPA5Y6EapZhPR+SX_qDfLe+4QR-w@mail.gmail.com"
      type="cite">
    </blockquote>
    <br>
  </body>
</html>