NamedQuery for standard operation type

[krigu]

I have an legacy JPA-modell with a lot of eager loading associations, which makes some queries quite slow. For displaying only a couple values in a grid I'm trying to fetch only certain fields from an entity. I built a custom namedquery which fetches only a subset of all fields and it would be nice to "map" this query to the "standard" fetch operation (see .ds.xml). I found a sample in the docs (http://www.smartclient.com/smartgwte...tml#namedQuery) which works with a custom operation type.

<DataSource
        ID="KONTAKT_GRID"
        serverType="jpa"
        beanClassName="com.mycompany.server.custom.entity.kontakt.Kontakt"
        dropExtraFields="true"
>
  <fields>
    <field name="id" type="integer" primaryKey="true" hidden="true"/>
    <field name="name" type="string"/>
    <field name="vorname" type="string"/>
    <field name="aktiv" type="boolean"/>
  </fields>

  <operationBindings>
    <operationBinding operationType="fetch"  namedQuery="Kontakt.aktiv.lookup"/>
  </operationBindings>

</DataSource>

Can I somehow make smartgwt call the namedQuery for the default fetch-operation instead of building a select * from Entity query? Or is there another way of ommiting some fields from the database query?

Thank you

[Isomorphic]

You can use operationBinding.outputs to specify particular fields you want to return. Both this and the namedQuery option can be specified on the default fetch operation (as you've done - just omit the operationId).

Note also that the default behavior is only to return the declared fields to the browser, not every attribute - see also DataSource.dropExtraFields.

[krigu]

Thanks for the response Isomorphic! It works fine with operationBindings.output and also with a custom operationId.

However, I'm not sure if I'm missing the point, but the above sample .ds.xml is not using the namedQuery as expected. It does a Select * from entity Kontakt. Do I have to specifiy some other attributes to make the above datasource work?

[Isomorphic]

Are you saying that your namedQuery is not working at all (regardless of whether an operationId is specified) or that it just isn't working if you omit an operationId?

Note, there are reasons why used a namedQuery as the default fetch operation might be a bad choice, including the fact that automatic data paging has to be disabled (since we can't add that to arbitrary existing queries). So if you are just trying to limit columns, using operationBinding.outputs is a better choice, and if you are trying to impose default criteria, a <criteria> tag is probably better. See the QuickStart Guide for more capabilities that might let you avoid a NamedQuery, so you can avoid the limitations of that approach.

[krigu]

To clirify: the problem is with the extact ds.xml posted at the begining (#1, so no operationId). SnartGWT does not consider the namedQuery but does select all columns.

[Isomorphic]

That didn't answer the question. We are asking whether the namedQuery does work if you specify an operationId and use that operationId in your fetch attempt.

[krigu]

That didn't answer the question. We are asking whether the namedQuery does work if you specify an operationId and use that operationId in your fetch attempt.

Yes it does.

[Isomorphic]

FYI, the behavior from the original post is fixed and will be available in nightly builds since Dec 9 (tomorrow). NamedQuery will be picked up for the fetch operation if configured in operationBinding

[krigu]

Great!

Thanks for the feedback and the support isomorophic