locked
Dataservices and DynamicData RRS feed

  • Question

  • Hi,
    I'm writing an app using the DynamicData Preview 2 DLL's which provide us with DataServiceLinqDataSource - a datasource that can be used with DataServices.

    All is going fine, but I've hit a particular issue I'm stuck with.

    I've got some Many-to-Many relationships and to manage these in DynamicData I've created a ManytoMany field template (Based on David Ebbo's Entity Framework one).  This works fine in UPDATE mode, but in INSERT mode I hit a problem.

    The DataSource Inserting event sends LinqDataSourceInsertEventArgs as a parameter.  That's great, it's got the "NewObject" in it.....
    In this event I need to add some records to the context to form my many-to-many relationships.  OK, So I create a DataContext (It's not passed in, so I can't use the same context as NewObject.....Can I?) and setup my new records and links....everything works fine until I hit "SaveChanges".  I can't save changes because the entity doesn't exist yet.  OK, I'll ADD it to my context instead of ATTACH ing it.....Can't do that either as I get another error back.
    This would be so much easier if the DataSource's context was passed in with the event arguments like it is with the EntityDataSource.

    Putting it simply.....Using DataServicesLinqDataSource and a DynamicData custom field template, how can I ensure my database changes are done under the same context as the DynamicData changes?

    Dave
    Tuesday, March 10, 2009 3:55 PM

Answers

  • As I suspected, it was me being daft.
    Although both the ContextCreated and the Inserted events pass LinqDataSourceStatusArgs as an event arguments parameter, the Result object within it contains different things for each!
    In ContextCreated, it is the context.
    In Inserted, it is the new record that has just been inserted.

    So, If I do my Many-to-Many updates in the Inserted event, I can use the newly created object in my context quite happily.

    This still isn't ideal, though.  I can't see a way of doing an Atomic Insert with both the New record and the many-to-many relationships for it.  They will always be split into two transactions by DS which sounds like something that should be fixed to me. 
    My suggestion would be that where the context.Attach and context.Add methods return "It's already there, you can't xxxx it" they just ignore the fact that it's already there and carry on processing.  Why is it an error?  Just pretend it has just been added/attached and carry on.
    Doing this would allow me to put my many-to-many updates into the same transaction as the creation of the new object.
    • Marked as answer by Dave Russell Wednesday, March 11, 2009 10:42 AM
    Wednesday, March 11, 2009 10:42 AM

All replies

  • ....I had a bright idea and built a handler for the ContextCreated event.  This is great, it gives me the Datacontext in e.Result.....But the record I want to add many-to-many relationships for isn't in the context when the DataSource_Inserting event fires!
    If I attach it I get an error further down the line "...Is already being tracked by the context" from the DetailsView.InsertItem() triggered by the save button.  if I don't add it, or attach it, I can't build my many-to-many relationships for it.

    Catch22?

    Anyone help?

    Am I missing something really basic?
    Tuesday, March 10, 2009 4:17 PM
  • As I suspected, it was me being daft.
    Although both the ContextCreated and the Inserted events pass LinqDataSourceStatusArgs as an event arguments parameter, the Result object within it contains different things for each!
    In ContextCreated, it is the context.
    In Inserted, it is the new record that has just been inserted.

    So, If I do my Many-to-Many updates in the Inserted event, I can use the newly created object in my context quite happily.

    This still isn't ideal, though.  I can't see a way of doing an Atomic Insert with both the New record and the many-to-many relationships for it.  They will always be split into two transactions by DS which sounds like something that should be fixed to me. 
    My suggestion would be that where the context.Attach and context.Add methods return "It's already there, you can't xxxx it" they just ignore the fact that it's already there and carry on processing.  Why is it an error?  Just pretend it has just been added/attached and carry on.
    Doing this would allow me to put my many-to-many updates into the same transaction as the creation of the new object.
    • Marked as answer by Dave Russell Wednesday, March 11, 2009 10:42 AM
    Wednesday, March 11, 2009 10:42 AM