You could create a second mapping, with a different name as a read only entity and then not map the collections that are not required. This should work well for filling the grid.
John Davidson On Wed, Jul 6, 2011 at 10:09 AM, Joe B <[email protected]> wrote: > I'm in crunch mode on this rather large project going to production > here soon .. and I'm running into unexplicable issues with the > Criteria API, FetchMode, and performance. > > I'm trying to retrieve a LARGE set of WIDE entities with a number of > collections that, for performance reasons, I do not need to query. > > The purpose of this query is to return a grid list of data to the > user: His/Her work tickets, filtered by the user & group created or > assigned to. > > So, this list is going to return, at most, 500 results, but still it's > taking too long. In the grid, the user does not need to see the sub- > entity-collections, so we would like to prevent these from being > queried for so that we don't have to transfer them over the wire to > the client. > > My only 'solution' to this has been to set FetchMode.Lazy on the > query, then before committing the transaction, loop through each > result and set the collection properties null to prevent NH from > retrieving them when the entities are serialized and sent to the > client. > > (This /can't/ be the optimal solution!). > > But, this doesn't work! The collection is fetched regardless of the > FetchMode I specify. Even more confusing, is I've got another entity > hierarchy mapped EXACTLY the same, but when I do a query for it, > without specifying a fetch mode, the child collection is lazy loaded. > This is actually how i stumbled upon this 'solution' > > > Because the grid list of entities displays only a subset (albeit 15 > columns) of the properties on the entity itself .. should I be going > about this a different way? I've thought about creating another entity > specifically for this grid that only mapped what I needed, back to the > same underlying table ... but is that absolutely necessary? Also, that > would seem to nullify any benefit of caching the Ticket entities if > what is searched for and what is edited are completely different, and > indeed would make my cache footprint at least 1.5x larger, having to > store duplicate data that it doesn't know is the same .. > > any advice is greatly appreciated.. > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
