And if I configure other relationships to that item using SetLink prior to saving changes they are linked correctly, so the context does handle the value accordingly. When looking at the actual network traffic using Fiddler, I can see that the initial upload of the binary data actually does return the information for the item along with its ID. OrderByDescending(x => x.Id).First() to get the recently created item. I would prefer to have to avoid strange lookups that ultimately could fail during heavy load, such as using. From the Manage Document Library view, you can drill-down in the list of folders. I initially thought this was a bug in the first version of WCF Data Services so I updated to the latest, 5.4.0. Additionally, you might need to upload generic documents that are not. Var newId = someOtherEntity.Id //this will instead always have 0 Var someOtherEntity = new SomeOtherEntity Ĭontext.AddToSomeOtherEntityItems(someOtherEntity) Ĭontext.SetSaveStream(someOtherEntity, data, true, "SomeMIMEType", "SomeSlugPath") For example: SomeContext context = /* creation of the context*/ However, if what you are creating is an item for a document library, the id doesn't seem to be updated on the saved entity. Var newId = someEntity.Id //this will have the new id Meaning: SomeContext context = /* creation of the context*/ Ĭontext.AddToSomeEntityItems(someEntity) With regular Sharepoint lists items, when saving the changes to the context, the id of the new item is automatically populated on the original object. I'm currently consuming information from Sharepoint 2010 using WCF Data Services from C# (an asp.net mvc4 application).
0 kommentar(er)
