locked
relationship graph RRS feed

  • Question

  • Using ADO.Net Data Services says:

    "Since the result of traversing a relationship through a navigation property is another set of entities, you can continue to add navigation properties to the URL to navigate through the relationship graph specified in the data service schema. For example, /Customers(‘ALFKI’)/Orders(1)/Employees returns the employees that created sales order 1 for the customer with a key of ‘ALFKI’. "

     

    I am confused as to what use case multiple navigation is when you have to know the primary keys?  In the above example, If I have to know Orders(1), then why would I ever need to start with /Customers("key").  I could just start with Orders(1).  Maybe I just can't see it yet, but what case would require this form of multiple navigation?

    Tuesday, November 4, 2008 11:15 PM

Answers

  • What if someone wanted to disallow top level access to orders. In your example above, i can see some services who didn't want to allow Orders access at all. They wanted customers to see their orders and hence could force them to access via their customer entity.

     

    Also, we are looking into containment feature, where you can explicitly say parent -child relationship and say that do not allow access to child directly, but only through the parent.

     

    Thanks

    Pratik

    Wednesday, November 5, 2008 5:49 PM
    Moderator

All replies

  • You can use the slash notation to (for instance) fetch Customer ALKFI, and all it's Orders and all Orders' Employees like this: 

    /Customers(‘ALFKI’)?$expand=Orders/Employees



    This way, you 'll join fetch the Customer ALFKI's Orders and these Orders' Employees in one single query.
    And you don't need to know the orders' primary keys. The query will result in an inner join on your foreign key.


    Regards,
    Koen
    Wednesday, November 5, 2008 9:27 AM
  •  Koen j wrote:
    You can use the slash notation to (for instance) fetch Customer ALKFI, and all it's Orders and all Orders' Employees like this: 

    /Customers(‘ALFKI’)?$expand=Orders/Employees
    This way, you 'll join fetch the Customer ALFKI's Orders and these Orders' Employees in one single query.
    And you don't need to know the orders' primary keys. The query will result in an inner join on your foreign key.

    Regards,
    Koen

     

    Thanks Koen.  I understand the 1-many need.  I was more asking why the 1 to 1 navigation (in the doc) like below would be needed:

    /Customers("id")/Orders(1)...

    Because if I know Order 1, I don't need to start with Customer(x) as that would be redundant.

    Wednesday, November 5, 2008 5:07 PM
  • What if someone wanted to disallow top level access to orders. In your example above, i can see some services who didn't want to allow Orders access at all. They wanted customers to see their orders and hence could force them to access via their customer entity.

     

    Also, we are looking into containment feature, where you can explicitly say parent -child relationship and say that do not allow access to child directly, but only through the parent.

     

    Thanks

    Pratik

    Wednesday, November 5, 2008 5:49 PM
    Moderator
  • ah.  That makes sense.  Thank you Pratik.

    Thursday, November 6, 2008 4:13 AM