locked
LINQ to SQL Beta2 to RTM Key Changes

    General discussion

  • Here is a quick preview of forthcoming changes in RTM compared to beta2:

     

    1. Renaming of methods on Table<T> / ITable

    We got substantial feedback after beta1 and at conferences indicating that Add()/Remove() methods were confusing or misleading for many users. The semantics of an INSERT or DELETE at the time of SubmitChanges() was not clearly conveyed by Add()/Remove(). The new names InsertOnSubmit()/DeleteOnSubmit() are more descriptive of the actual semantics. Note that there is no change in semantics - just a name change.

     

    Previous Method
    (Beta1 and Beta2)

    Renamed Method
    (VS 2008 RTM)

    Add()

    InsertOnSubmit()

    AddAll()

    InsertAllOnSubmit()

    Remove()

    DeleteOnSubmit()

    RemoveAll()

    DeleteAllOnSubmit()

     

    2. Addition of a parameter to the validation hook OnValidate()

    This is a void method in beta2. The signature in RTM will be

     

    partial void OnValidate(System.Data.Linq.ChangeAction action);

    Where

    namespace System.Data.Linq {

    public enum ChangeAction {

    None = 0,

    Delete,

    Insert,

    Update

    }

    }

     

    This was an omission in our design that came up during the discussion of related bugs. The new signature gives the necessary control

     

    3. Enabling of local method calls

    In beta2, some of the VB XML features could not be used in a LINQ to SQL query since they required local method calls in projection in queries. Here is an example:

       Dim document As XDocument = _

       <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

       <SalesData>

           <%= From customer In db.Customers _

                Select <Customer name=<%= customer.CustomerName %>/> _

            %>

       </SalesData>

     

    In RTM, this query will work since LINQ to SQL will allow local method calls in projection - not just constructor calls as is the case in beta2.

     

    "Orcas" (Visual Studio 2008) product cycle has been very short so unlike traditional betas, this time around we have had almost no time to do any feature work after beta2 release. The focus has been on fixing bugs - especially customer-reported bugs, rounding out the edges and usual product staples like performance and stress testing.

     

    While the bugs fixed are too numerous to list here, here is a short list of key bugs that came up on this forum and customer emails. The following fixes for these bugs will appear only in RTM.

    1. Correct handling of database-generated GUID key values

    2. Cleanup of entity references corresponding to foreign key values in deleted objects

    3. Handling of Distinct() in certain queries

     

    Thoughts, comments, questions are welcome!

     

    Thanks,

    Dinesh

    Monday, August 27, 2007 5:00 PM

All replies

  • Hi,

     

    Thanks for the heads up.

     

    Does this mean there isn't going to be another public release of VS2008?  Or is there another release planned, which doesn't include these changes?

     

    Thanks,

     

    Ben

     

    Monday, August 27, 2007 7:34 PM
  • Beta2 will be followed up by RTM of VS 2008. There is no other expected release in between.

     

    Monday, August 27, 2007 7:38 PM
  • I am concerned with the change regarding Add/Remove. Why are you wanting to move away from the IList interface implementation? It seems that adding the new methods just confuses the user more than clarifies it. I understand the challenges with querying for values not yet committed, but it would seem easier to modify the identity tracking service checks on queries for new/removed items than to revamp or abandon the IList interface.

     

    I was actually about to recommend using AddRange rather than AddAll as it would seem to agree more with the existing framework naming conventions. I was trying to implement something earlier today and expected AddRange to be available and was surprised to see that the implementation used a slightly different name (AddAll). The framework is hard enough to learn. Why intentionally make it more difficult to do when existing method signatures seem to suffice?

     

    Items 2 and 3 sound like good changes. I think the local method calls in XML literals worked in the May 2006 CTP, so I am glad to see it back again.

     

    Jim Wooley

    http://devauthority.com/blogs/jwooley

    http://www.LinqInAction.net

    Tuesday, August 28, 2007 12:37 AM
  • Jim.

     

    Thanks for the feedback. Apart from giving advanced notice, feedback and commetns are also important part of this process.

     

    The original goal was to use existing Add()/Remove() pattern on collections. The problem was that the semantics is quite different - it is not like an Add()/Remove() on collection. The intent and the action is INSERT and DELETE database operations and those too only upon SubmitChanges(). This caused significant confusion on two fronts:

    1. I want to INSERT or DELETE, how do I do it? Database folks kept looking for API methods with similar names

    2. Why is this collection method not behaving just like a normal IList.Add()/Remove()?

     

    You are right in pointing out the familiarity of Add()/Remove() and similar methods for framework users. Likewise, Insert, Delete etc. are very familiar to database users. So it is a delicate tradeoff between the two. We have tried to pick names based on how close the semantics are to one or the other. For example, EntitySet.Add()/Remove() remain as they are since these operations are closer to collection membership changes than Inserts/Deletes in database (e.g. an Employee added to a Department's Employees collection may not be a new Employee).

     

    Dinesh
    Tuesday, August 28, 2007 4:43 AM
  • Your post really gets me worried. No more beta, RTM is coming next? I hope you know what you're doing...

    LINQ to SQL is an extremely promising technology. It really simplifies data access, provides static type checking and refactoring, integrates nicely with the language, etc. You know what the benefits are.

    But it is really, really not mature yet [at least in beta 2]. I am programming data access on a daily basis since it's an important part of my job. I have been using LINQ to SQL in a small and simple project to evaluate it. And as much as I would like to use it in other projects, I simply can not push it into my company. It just isn't good enough yet. Even in a very simple setting I have spent hours working around LINQ to SQL issues and limitations.

    I can only hope that you know what you're doing and you won't get stuck into a poorly designed v1. RTM is the last time you can make big API changes without breaking compatibility.

    BTW if there's just one single feature I can ask for in RTM it would be that EntitySet implements INotifyCollectionChanged. Not being able to directly bind to associations is just creating too many problems (I'm using WPF for the presentation layer).
    Tuesday, August 28, 2007 3:19 PM
  • >>You are right in pointing out the familiarity of Add()/Remove() and similar methods for framework users. Likewise, Insert, Delete etc. are very familiar to database users. So it is a delicate tradeoff between the two. We have tried to pick names based on how close the semantics are to one or the other. For example, EntitySet.Add()/Remove() remain as they are since these operations are closer to collection membership changes than Inserts/Deletes in database (e.g. an Employee added to a Department's Employees collection may not be a new Employee).<<

    Thanks for this clarification. Makes more sense now!
    Tuesday, August 28, 2007 5:35 PM
  • With the Change of the names of the Add and Remove methods, will the ChangeSet's collections be renamed to InsertedEntities and DeletedEntities too?

     

    And what about EntitySet's Add and Remove methods?  Are they being renamed too?

     

    Wednesday, September 05, 2007 3:43 AM
  • I asked Matt the same question - the answer is that EntitySet's Add and Remove methods will still be called Add and Remove.

    Regards

    Joe
    Wednesday, September 05, 2007 10:10 AM
  • Thanks.  That seems inconsistent to me.  And, I hope Dinesh will answer the part about the ChangeSet.

     

    Wednesday, September 05, 2007 1:34 PM

  • Thanks for the heads up.

    One question:

    - Will the code generation issues that have been mentionned on the forum be taken care of? (namely calling OnCreated after instantiating the EntitySets, and the primary key update for 1 to 1 relationships)

    Looking forward for the detailed list of fixes/enhancements.
    Thanks for all your efforts guys. I'm personally very excited about the Linq to SQL (and Linq in general) technology.
    Wednesday, September 05, 2007 1:56 PM
  • Answer to Joe's questions:

     

    As mentioned above, EntitySet.Add()/Remove() remain unchanged. ChangeSet is still has three collections: Inserts/Updates/Deletes

     

    Thanks,
    Dinesh

     

    Tuesday, September 11, 2007 4:45 PM
  • Denis,

     

    I do recall taking several code gen event issues and 1:1 PK update issue as well. But just to be certain, do you have the specific post / connect bug you are referring to? I want to make sure that we are referring to the same issue.

     

    Thanks in advance,
    Dinesh

    Tuesday, September 11, 2007 8:20 PM
  • Just thought I would bring this post closer to the top of the forum now that RTM is here...

     

    Tuesday, November 20, 2007 8:52 PM
  •  jods wrote:

    BTW if there's just one single feature I can ask for in RTM it would be that EntitySet implements INotifyCollectionChanged. Not being able to directly bind to associations is just creating too many problems (I'm using WPF for the presentation layer).

     

    So does EntitySet implement INotifyCollectionChanged in rtm?

    Wednesday, November 21, 2007 12:53 AM
  • Unfortunately, it does not.

    Wednesday, November 21, 2007 1:13 AM
  • Does this help things?

     

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=295116

     

    Wonder did it make to rtm?

     

    Wednesday, November 21, 2007 1:52 AM
  • The scenario described there is fixed in RTM, but it's only the surface of the problem, and not a complete solution.

    Wednesday, November 21, 2007 4:01 PM
  •  

    hey one more problem tables with the same names in different databases will cause an error?

     

    did they fix it?

    Monday, December 03, 2007 2:11 PM
  • ilkon,

     

    When dealing with tables from different databases, I would recommend using a different namespace for each database. Alternatively, you can somehow disambiguate the table names. The underlying issue here is the classes that are generated. If you generate two classes in the same namespace (through the LINQ to SQL designer or SqlMetal) with the same name, you will end up with this conflict.

     

    Jim Wooley

    http://www.devauthority.com/blogs/jwooley

    Monday, December 03, 2007 2:58 PM
  •  

    using a different namespace ......... BUT HOW?  I use drag and drop?????? Do I do it before that?
    Monday, December 03, 2007 3:06 PM
  • Aim: When an update happens on Entity1 I am trying to insert a new instance of Entity2.

     

    Conceptually, this is what I tried:

     

    In the UpdateEntity1 partial extension method on the DataContext, I tried the following:

     

    parital void UpdateEntity1(Entity1 instance)

    {

    Entity2 myNewEntity = new Entity2();

    this.Entities2.InsertOnSubmit(myNewEntity);

    this.ExecuteDynamicUpdate(instance); 

    }

     

    This throws an exception:

    The operation cannot be performed during a call to SubmitChanges.

     

    Is there a workaround or another solution?

     

    Thanks,
    Jay

     

    Friday, January 04, 2008 4:11 PM
  • BTW if there's just one single feature I can ask for in RTM it would be that EntitySet implements INotifyCollectionChanged. Not being able to directly bind to associations is just creating too many problems (I'm using WPF for the presentation layer).

     

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=354250

     

    It can't hurt to try...

    Monday, June 30, 2008 6:11 AM
  • thanks for the link AKS... found useful to some extent...

    microsoft crm implementation


    Tuesday, August 12, 2008 6:38 AM
  • Thanks a lot. This helped me to solve my Problem
    - Aditya Marla
    Wednesday, January 20, 2010 12:15 AM
  • Hi Dinesh, Great work... very nice informative post... thanks...

    microsoft crm implementation

     


    custom sharepoint development
    Wednesday, March 24, 2010 6:58 AM