This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi It seems that when a View is used with a Find<> query, any eager loading SQL statements that get generated in the same batch do not make use of the specified View e.g. Find<Property>(new Query generates: exec sp_executesql N'SELECT
where the expected behaviour would be: FROM for all the queries, not just the first, rather than: FROM Cheers, Donovan.
|
|
|
Hi Donovan, Thanks - we have tracked this one down and committed a fix for this which will show up in future nightly builds (20090409 and higher), let us know how you get on with this :)
Jeremy |
|
|
Thanks for letting us know about this. We've fixed the issue and the fix will be included in nightly builds dated 9 Apr 2009 and above, available from about 1430 GMT. |
|
|
Hi, finally got round to testing this fix. It does exactly what it says on the tin and solved my intial problem which is great! Thanks very much for the speed of response!! I put it to test with the following view: IF EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[PropertiesWithCurrentStatus]'))
Perhaps an attribute, similar to Transient, would be useful. Something like Optional or ReadOnly, or even ViewOnly maybe, which attaches the column to a specific view. Haven't tried it yet, but I guess that giving all the non-view properties in the entity an aggregate name would solve the problem from a different angle. Basically, the requirement is to have extra column(s) in a view for an entity which can be easily excluded from normal operations on that entity. Is there a simpler way of doing this that already exists? Cheers, Donovan.
|
|
|
Thanks for the suggestion. This could be a little bit tricky for us to implement, so I'd initially suggest exploring the named aggregate / lazy-load approach. Aggregates are our way of representing load strategies so they're probably the appropriate way of representing this, though they're not be a perfect fit -- you'd need to synchronise your use of aggregates with your use of views -- but I think it would be useful to see if they can address your current requirement (and, if not, where they fall short) before implementing anything new. |
|
|
Hi Ivan, lazy loading seems to cover the additional view columns that may occur. Looked at the code generated for the LockVersion property and it seemed to match the bill and so got away with this: public partial class Property { ..... [EagerLoad(AggregateName = "WithCurrentStatus")] ..... } which allows this statement to work: Find<Property>(new Query but does feel a bit kludgy, and it wouldn't work for a Linq WHERE statement. I suppose the real requirement is for every view to be able to have associated server-generated read only columns which are queryable, but read-only. This would avoid the need to remember to have a matching pair of ViewName and AggregateName for every query. It works for now, but interesting edge use case to consider. Cheers, Donovan.
|
|