none
Related Sharepoint Lists Missing Navigation Properties - BUG?

    Question

  • Hi,

    There are missing navigation properties on the parent side of a relationship between two SharePoint lists - Why?.

    In addition to losing all the benefits of the navigation properties, it breaks the new built-in SharePoint Upload Control.

     http://social.msdn.microsoft.com/Forums/vstudio/en-US/c818ced8-c995-43e8-92a3-7c0d8c509f8d/integrating-document-libraries-in-march-2014-with-sp-list-as-parent-entity?forum=lightswitch

    When you connect to two SP lists which are 'related' using a lookup column, you don't get a navigation property on the parent side and the relationship is not editable.  Also the relationship is not editable in the relationship window.  As a workaround,  I modified the entity .lsml for the document library (Documents.lsml in my case)

    Removed this text from the .lsml in data sources directory:

            <NavigationProperty.Attributes>
              <Hidden />
            </NavigationProperty.Attributes>

    After that change is made, you can name the Navigation Property on the parent side and it's fixed.

    For example,  I have a SP list called 'Contacts' and a library called 'Documents'.  There is a lookup column in Documents that relates the items to a Contact.  This lookup becomes a relationship in LS and the documents entity has a navigation property to Contact.  However, the Contact entity does not have a navigation property to Documents.  As a result the upload control doesn't work because it checks for association links and if not present it pukes an error and quits.

    To fix this I edited the Documents.lsml and removed the above code and then added a nav property on the Contacts side of the relationship.

    It would be nice if the navigation properties were on both side of the relationship to begin with as this will likely have to be repeated every time you 'Update Data Source' 

    Is this a bug?

    HTH,

    Josh







    • Edited by joshbooker Tuesday, March 11, 2014 7:15 PM images
    Tuesday, March 11, 2014 6:20 PM

All replies

  • Hello Josh,

    I would consider this as a currently unsupported scenario.  The reason why the navigation property does not exist on both sides of the relationship is because this is how the relationship is exposed on the SharePoint OData feed (ListData.svc) that LightSwitch uses to access SharePoint data.  SharePoint does not expose the relationships as bi-directional.  As you noted you can modify the lsml so that LightSwitch will create a navigation property on both sides of the relationship, however the navigation property is not fully functional.  The reason it is not fully functional is because the SP OData feed does not have the navigation property which LightSwitch relies on.  For example the navigation property you created cannot be eagerly loaded, it be used within any type of query restriction, it be used within a query sort, etc.

    Michael

    Wednesday, March 12, 2014 2:14 PM
  • Michael,

    Thanks for your reply.  I'll test the scenarios you mentioned and report back.  All I know is that I can add the related documents to a screen based on contacts and the screen works. As does the built-in upload control which is otherwise useless since it requires the nav property on the parent side - big fail!

    Why can we not create virtual navigation properties between entities of the same data source?  Wouldn't that solve the problem of a missing nav prop in SP?

    Thanks again,

    Josh

    Wednesday, March 12, 2014 2:23 PM
  •  As you noted you can modify the lsml so that LightSwitch will create a navigation property on both sides of the relationship, however the navigation property is not fully functional.  The reason it is not fully functional is because the SP OData feed does not have the navigation property which LightSwitch relies on.  For example the navigation property you created cannot be eagerly loaded, it be used within any type of query restriction, it be used within a query sort, etc.

    I found you're right the property simply doesn't show up in the sort and filter areas of the query designer on the parent entity.  As a result, we cannot filter and sort on it, but it doesn't appear to cause any issues.  Certainly not ones that outweigh the benefits including:

    Ability to 'Add Documents' on a screen which is missing without the nav prop on Contacts:

    Is there another way to do this without the nav prop? (besides adding a docs parameterized query with screen properties, etc. since that basically required a complete redo of the relationship and doesn't behave the same as above)

    Ability to use built-in Upload control:

    What's the harm in adding a less-than-fully-functional nav prop?  Is that not better than none at all?

    TIA,

    Josh


    • Edited by joshbooker Wednesday, March 12, 2014 3:08 PM is there another way?
    Wednesday, March 12, 2014 3:04 PM
  • Josh,

    The query designer does not currently support filtering on collection properties.  You would have to write the type of queries I am referring to via code.  For example the following query would not be supported in this scenario:

    partial void ContactsWithDocuments_PreprocessQuery(ref IQueryable<Contact> query)
    {
        query = query.Where(c => c.Documents.Any());
    }

    I realize in your scenario providing this navigation property would solve your needs, I am just trying to illustrate that it does not have the functionality that other navigation properties have.

    We certainly appreciate your feedback on this scenario.  This feedback is important to us when planning our next release.

    Michael


    Wednesday, March 12, 2014 3:38 PM
  • Thanks again Michael.  Can you comment on adding the related documents to a screen?

    Is there another way to do this without the nav prop? (besides adding a docs parameterized query with screen properties, etc. since that basically required a complete redo of the relationship and doesn't behave the same as clicking 'Add Documents')

    Also, it appears you cannot use virtual relationships in the way your describe either, yet the relationship do have nav props on both sides:

    I have a virtual relationship between an intrinsic entity Account and a SP library and with this code:

            Private Sub AccountsWithDocuments_PreprocessQuery(ByRef query As System.Linq.IQueryable(Of LightSwitchApplication.Account))
                query = query.Where(Function(c) c.Documents.Any)
            End Sub

    I get this:

    The same error as with my workaround nav prop.  Is the VB incorrect, or do the same limitations that your describe also apply to virtual relationships?  If the latter, then why is the workaround not supported scenario - why not add the nav prop on the parent side of a sharepoint relationship?

    TIA,

    Josh




    • Edited by joshbooker Wednesday, March 12, 2014 5:39 PM
    Wednesday, March 12, 2014 3:44 PM
  • Hi Josh,

    As I initially said, the scenario you are trying is not something supported at this time.  That being said, there is another workaround but it too has some cons which may or may not matter depending on your scenario.  If you can replace the Contact.Documents relationship within SharePoint with a simple document foreign key property, then within LightSwitch you can attach to SharePoint twice.  One that attaches to the Contact and another that attaches to the Document Library.  Once this is done you can then define a virtual relationship between the two.

    Lastly regarding your question about the virtual relationship query.  Virtual relationship properties are not queryable because the data on both sides of the relationship reside in different data sources.  A query containing a virtual relationship cannot be passed to either data source to execute because the data sources do not know about each other.

    -Michael

    Wednesday, March 12, 2014 8:02 PM
  • Hi Josh,

    Thanks for reporting this. As Michael mentioned before, this scenario is currently not supported but we appreciate your feedback. Meanwhile, please make sure you submit this scenario to the Uservoice too.

    Thanks,

    Chakkaradeep

    Program Manager, Cloud Business Apps.


    Regards,
    Chakkaradeep | http://twitter.com/chakkaradeep | http://www.chakkaradeep.com

    Friday, March 14, 2014 12:21 AM
  • Thanks Chaks for your reply.

    I will post a suggestion on uservoice, but your link is to the SharePoint category.  We normally do so under the LightSwitch category.  Has that changed?

    TIA,

    Josh

    Friday, March 14, 2014 1:33 AM
  • Hi Josh,

    Yes, going forward you can submit suggestions for Cloud Business Apps in the Visual Studio Office/SharePoint Uservoice portal.

    Thanks,

    Chaks


    Regards,
    Chakkaradeep | http://twitter.com/chakkaradeep | http://www.chakkaradeep.com

    Friday, March 14, 2014 4:26 AM
  • Chaks,

    I went to add a couple suggestions on uservoice, but I'm out of votes so I cannot post a new idea.  Is there anyway to get VS team to enable folks to have more than a measly 3 votes?  Other uv categories allow 5 votes or more.  I suppose I could provide another email address, but that's a shame.

    TIA,

    Josh

    Thursday, March 20, 2014 1:08 PM
  • You should have 10 votes total for the Visual Studio UserVoice site. It's likely that you have votes already used on other pending ideas.

    Justin Anderson, LightSwitch Development Team

    Friday, March 21, 2014 5:07 PM
    Moderator
  • @Angie & @Ravi,

    Please don't go marking questions as "answered" just to close them off. Josh is more than capable of deciding if his question has been answered by any post. If he hasn't chosen a post as the answer, it'll be because he doesn't consider his question "answered", therefore the question should remain open.

    Routinely closing questions, just to reduce the number of "unanswered" questions, means that:

    • people don't even try to answer the question any more, because it looks like it's already been answered, when in fact the OP doesn't consider it to be answered at all
    • this dilutes the efficacy of the forum as a place for members to FIND actual answers, not think they've found an answered question, only to find that a moderator has just marked the question as answered for the sake of some forum stats

    @Josh,

    If you feel a post has answered your question (even if it's not the answer you were hoping for) then please mark it accordingly. If not, the question should remain "unanswered". Please feel free to unmark any post that has simply been closed by a moderator.

    Yann Duran
         - Co-Author of Pro Visual Studio LightSwitch 2011
         - Author of the  LightSwitch Central Blog

    FREE Download: Luminous Tools for LightSwitch
    (a Visual Studio productivity extension for LightSwitch)
     
    Click Mark as Answer, if someone's reply answers your question
    Click  Vote as Helpful, if someone's reply is helpful
     
    By doing this you'll help everyone find answers faster.


    Sunday, April 20, 2014 1:03 AM
    Moderator