1

Closed

Runtime loads pre-generated views by index - prevents from loading views lazily in the feature

description

Currently a class that allows mapping pre-generated views is derived from EntityViewContainer and has to implement ViewCount and GetViewAt abstract methods (I think it was done to be able to generate the has over esql which we already remove). This means that even though we got rid of the hash over generated e-sql code cannot load view lazily. Instead we should load views differently - e.g. by using the extent/entitySetBase name. AFAIK we have always had an extent->ESQL dictionary that contained both update and query views and we even return this dictionary from GenerateViews inside the view group. Note that there is one dictionary like this per each mapped container. One thing that should be investigated is how this is supposed to work if an entityset from CSpace has the same name as an entityset from SSpace. In that case we would end up having a conflict since keys in the dictionary are the same.

Ideally we should make this change in EF6 since we have already taken a number of breaking changes in this area.

Bonus: review comments (and possibly dead code) and remove ones that talk about hash over text e.g.:
        ///     3. Generate the hash for all of the view text in the EntityViewContainer and
        ///     this hash should be the same as the stored on in the EntityViewContainer
       private void SerializedAddGeneratedViewsInEntityViewContainer

        //Collect the names of the entitysetbases and the generated views from
        //the generated type into a string so that we can produce a hash over it.
        private void SerializedAddGeneratedViews(
Closed Jul 18, 2013 at 12:37 AM by maumar
Verified, that new mechanism loads view via extent, rather than index, closing

comments

RoMiller wrote May 24, 2013 at 6:09 PM

EF Team Triage: Emil is working on these bugs.