So what exactly is SPMeta2 doing? Fiddler comes to the rescue.
It’s definitely possible to understand XML in requests send by CSOM to the server. But in this example I’ll use CSOM inspector fiddler extension that makes it a bit easier.
Just to remind what we try to accomplish:
- create site column
- create content type
SPMeta2 content type,
- create list
SPMeta2 content type,
SPMeta2 content typeto
- Loads field by GUID (it was required) using ExceptionHandlingScope.
- Loads field by internal name using ExceptionHandlingScope. I must say it’s clever to fallback to internal name. Still no need to use 2 separate calls for that.
- Creates field and set its properties.
- Load content type by CTID using
LoadQuery. I don’t even need to look at the code to see how inconsistent it is.
- Creates content type and set its properties.
- Sets some more content type properties and update. Could’ve been done in previous call.
- This is where fun begins. It gets content type by CTID (again), but doesn’t actually call
Loadmethod. This call is completely pointless.
- Gets the same content type AGAIN. This time
Loadis executed, but it doesn’t change the fact, it was just created, so there’s no need to load it at all.
- Gets the field by ID without calling
- Gets the same field AGAIN, with
Loadthis time. Yeah the field that was created and doesn’t need to be loaded.
- Adds field link to content type and calls
- Calls update on the same content type AGAIN. Because reasons.
Web.Url. One is already loaded, another could be in call
Web.Url. Yes. AGAIN.
- Gets list by Url using ExceptionHandlingScope.
- Creates list and sets its properties.
- Gets root folder of the list.
- Loads all items form property bag of the root folder. This will not be used anywhere.
- Gets list by ID. Yes the list that was already loaded. Loads all properties, that will never be used.
- Sets properties of the list and updates. This could’ve been done in step 17.
- Gets root folder of the list again. Loads properties like
ItemCountwhich is required for what exactly?
- Loads all items form property bag pf the root folder. AGAIN. Seriously? There is absolutely NOTHING relevant to provisioning there.
- Loads list and all it’s properties, again…
- Loads list and all it’s properties. Yes again. Only difference between those two is correlation id.
- Calls update on list and web. And it didn’t even use those list properties…
I’m glad it’s finally over. And I think I could stop there, but I feel like
26 deserves more attention.
Only thing happening here is
Update on list and web. This shows that SPMeta2 developers lack knowledge of
how CSOM works.
SPList objects on the server are not cached or in any way persevered between
calls. That means fresh instances of those objects are actually retrieved from the database, no changes
are applied and empty
Update is executed. It’s not only pointless, it’s a waste of every resource along
How to do it better
Knowing what went wrong we can do better. That’s the subject of next post.