locked
Some questions for the team RRS feed

  • Question

  • Hi guys;

    As I'm learning more of ADO.Net Services (Astoria), more questions came up. When I was looking into Linq To SQL, one of the issues that I brought up and was never addressed in RTM, was the fact, every time you make changes to Database Schema (particularly during development phases), there is no way in Linq to SQL to sync that up. You have to delete the tables and re-import them back in. It seems, one obvious scenario (change to schema) was ignored. I even suggested that the designer should have a feature that developer can ask the designer to sync with database. That's between Database and Linq to SQL system. I have not looked into it's big brother, Entity Framework designer yet.

    Then last night as I was reading the docs, and realized, in order for developer to consume the data that is returned from Astoria to client, we need to have containers in the client that basically mirrors what's in the middle tier (Astoria) model, in order to query the data. To do that, the team has created "WebDataGen.Exe" to create our WebDataContext. And here it hit me again that now we have one more level of "Creating" the schema from the model that was created from the database. If we have a database that has 200 tables, and during development, we are adding and changing the schema as new features gets added, now we have another layer that needs to become synched with middle tier that needs to sync with bottom layer (database). This can create a lot of frustrations and waste of time among team members, and even worst, if the team members are not in close connectivity.

    If this is the case, are you guys looking to streamline this process?

    My second question regarding performance. The fact that we have two style of fetching data from the service is great. One via URL with parameters and one that client submit LINQ to Astoria. And both seem to have their own place to use. My question is which one yields to better performance for query and CRUD operations. The more I think about it from outside world, then I see they both should have same performance, but something tells me the URL with parameters might be faster.

    I hope I get some detail answers, particularly on first question.
    Thanks!

    Monday, December 24, 2007 3:10 PM

Answers

  • Answering the perf question first, there actually isn't a lot of difference perf wise between using URIs directly and using Linq to Astoria.  In fact, Linq to Astoria generates a URI from the Linq expression which is the extent of the difference between the two techniques (and the perf overhead).  After that, the remainder of the processing is the same for both scenarios (URI execution, object materialization, CRUD operations).

     

    As for your first question, currently Astoria does not support have a database migrations and relies on the developer to rerun the code gen tools or update the classes manually when the database schema changes.  There is a possibility this feature might be part of the EF designer for the RTM release.

     

    However, I want to point out that the Astoria client library is by design very decoupled from the types/ tables on the middle/ database tiers and if you make the client types open then one doesn't need to modify the client types when a column is added to a given table. In the near future, the same support will also be available for middle tier types.

     

    That said, supporting migrations for client & server types is an important feature although I see this more as a tools feature then an API feature.  Unfortunately, it probably won't make it into V1, but it is on our radar. 

     

     

    Friday, December 28, 2007 1:15 AM
    Moderator
  • The Astoria Silverlight library noted above is now release. See our blog post here for links: http://blogs.msdn.com/astoriateam/archive/2008/01/11/ado-net-data-services-silverlight-add-on.aspx

     

    As for code snippets, see the "Using ADO.NET Data Services" document here: http://astoria.mslivelabs.com/Using%20ADO.NET%20Data%20Services_CTP1.doc .  The section about the .NET Framework client library applies pretty much 1-1 to the SL lib. 

    Monday, January 14, 2008 4:25 AM

All replies

  • Answering the perf question first, there actually isn't a lot of difference perf wise between using URIs directly and using Linq to Astoria.  In fact, Linq to Astoria generates a URI from the Linq expression which is the extent of the difference between the two techniques (and the perf overhead).  After that, the remainder of the processing is the same for both scenarios (URI execution, object materialization, CRUD operations).

     

    As for your first question, currently Astoria does not support have a database migrations and relies on the developer to rerun the code gen tools or update the classes manually when the database schema changes.  There is a possibility this feature might be part of the EF designer for the RTM release.

     

    However, I want to point out that the Astoria client library is by design very decoupled from the types/ tables on the middle/ database tiers and if you make the client types open then one doesn't need to modify the client types when a column is added to a given table. In the near future, the same support will also be available for middle tier types.

     

    That said, supporting migrations for client & server types is an important feature although I see this more as a tools feature then an API feature.  Unfortunately, it probably won't make it into V1, but it is on our radar. 

     

     

    Friday, December 28, 2007 1:15 AM
    Moderator
  • Andrew, thank you for answering both questions.
    One unrelated question to the topic.

    I had asked Pablo, what's the best way to get a head start on SL and Astoria and he suggested I could use WPF as a client to use as a temperory client. And I thought the suggestion was great. Now my question is, how complete is the client version for WPF and secondly, how close the WPF client is to SL client version?

    Thank you in advance!
    Friday, December 28, 2007 1:58 AM
  • The Astoria Silverlight client library will be the same client API as the one that was shipped with the December CTP.  Initially, it will have a few features turned off mostly because of the lack of library support in Silverlight, but as Silverlight 2.0 gets closer to release, we anticipate the differences to be very minimal.

     

    We have a working version of the Astoria Silverligh client library which should be available very soon.  So stay tuned.

     

     

    Friday, December 28, 2007 2:06 AM
    Moderator
  • We have a working version of the Astoria Silverligh client library which should be available very soon.  So stay tuned.

    Andrew, that's fantasic news, except with one minor problem ;-) SL 2.0 won't be out for preview for at least another two months and I don't want to use SL 1.0 and JS. So, how do we solve this puzzle?
    Friday, December 28, 2007 3:18 AM
  • The preview of the Silverlight Astoria client library will work with the Silverlight 1.1 Alpha:

     

    http://msdn2.microsoft.com/en-us/silverlight/bb419317.aspx

     

     

     

    Friday, December 28, 2007 5:17 PM
    Moderator
  •  Andrew Conrad - MSFT wrote:

    The preview of the Silverlight Astoria client library will work with the Silverlight 1.1 Alpha:

     

    http://msdn2.microsoft.com/en-us/silverlight/bb419317.aspx

    Andrew, will there be docs and samples with this preview for SL.


    To be honest with you, when I installed VS2008 on my new machine, I didn't even bother to install SL1.1 SDK on it, because I got this new machine after ScottGu announced about the up comming SL2.0 Beta somtime around MIX08.


    So do you think with this Astoria Preview (for SL) I get enough leverage to go and install the SDK and start my project?

    Thanks!

    Friday, December 28, 2007 6:01 PM
  • Note - 2.0 is actually an newer version of 1.1, but with a new name.

     

    The Astoria client library we release for 1.1 Alpha will be almost as functional as the standard Astoria client library that was included with the December CTP.

     

    We will refresh the Astoria Silverlight client for Mix to work with Silverlight 2.0 preview.  No exact dates yet, but should be around the same time frame was Mix.

     

     

    Friday, December 28, 2007 7:04 PM
    Moderator
  • To add to what Andy has already said:

     

    1) regarding the need to update your "service reference" (what the command line tool outputs), we are currently exploring ways to streamline the webdatagen.exe experience (atleast to the level of syncing the client types with those exposed by a data service).  As Andy said these are unlikely to be there in V1, but we're actively looking for ways to get them online soon there after

     

    2) I will post to our blog (http://blogs.msdn.com/astoriateam) as soon as we get the SL library that works with the Dec 2007 CTP of Astoria out the door.  I expect this to happen in the first half of Jan 08.

     

    Cheers

    Mike

    Friday, December 28, 2007 7:15 PM
  • The Astoria Silverlight library noted above is now release. See our blog post here for links: http://blogs.msdn.com/astoriateam/archive/2008/01/11/ado-net-data-services-silverlight-add-on.aspx

     

    As for code snippets, see the "Using ADO.NET Data Services" document here: http://astoria.mslivelabs.com/Using%20ADO.NET%20Data%20Services_CTP1.doc .  The section about the .NET Framework client library applies pretty much 1-1 to the SL lib. 

    Monday, January 14, 2008 4:25 AM