I have just migrated my project to the Commerce 11 and found out that after the product import (custom import) all the links to the products has changed. Now all products are directly referenced under the catalog root.
As I understand this is caused by the primary category change mentioned here:
But I cannot find IsPrimary property on the NodeRelation as it is stated in the first link. How can I set the primary category?
Now when importing, I am setting just parent reference like this for the new product:
var productContent = ContentRepository.Service.GetDefault(parentReference);
And I am moving existing products:
var productContent = ContentRepository.Service.Get(productReference);
if (productContent.ParentLink != parentReference)
var newLink = ContentRepository.Service.Move(productContent.ContentLink, parentReference, AccessLevel.NoAccess, AccessLevel.NoAccess);
productContent = ContentRepository.Service.Get(newLink);
parentRefrence here is the link to the category it should be in (primary category).
All other categories are set by relations:
var oldRelations = RelationRepository.Service.GetParents(productContent.ContentLink);
foreach (var nodeRelation in oldRelations)
var relations = categoryLinks
categoryLink => new NodeRelation
Child = productContent.ContentLink,
Parent = categoryLink,
We are going to introduce NodeEntryRelation, and that's where you can set IsPrimary. It'll be included in Commerce 11.2, releasing this week :)
Thanks, Quan, but there should be some way to work with the current version too.
I am looking at the decompiled code for moving the content in the Commerce and I see that it adds default primary relation for the product. It takes the product's parent category link and the product's link when creating it.
I found in my code that I was creating another relation for the parent category and it might overwrite the primary one. But after the fix, it still doesn't work. :(
I hope there was (When it comes to business, I don't mind workarounds as long as they work) - but 11.2 is what you need. It contains a very nice performance improvment in promotion engine - so I recommend to upgrade instead.
I can send you the release packages for 11.2 if you want - they will take some times to get on the feed
I'm not quite following your description of the problem you are seing. If you use IContentRepository.Move on an entry, it will make sure there is a Relation with IsPrimary=true for the desired parent. That is, if there already is another primary relation it will be removed, and a relation to the desired primary relation is either added or updated (if it already exists but is not primary). So using the Move operation to set the primary category should work just fine.
The problem that I see with your code is if it runs in the order you have it in the post. Because after the move operation, you remove ALL the category relations including the primary one you just set by moving.
Good point Magnus. I haven't noticed that I am removing also the primary relation.
But if I cannot add the primary relation manually to the relations, why it is listed there?
Next, while Move should work, I couldn't find any place where the new primary relation is created for a new product.
It is listed because it is a relation like all others, just that it has the special primary flag the content provider uses to select the parent link. Not showing it seems to cause some confusion, but as Quan said, IsPrimary will be directly available on the relation object in 11.2.
For new entries, the ParentLink you use when creating it will be the primary relation.
Thanks for the clarification.
One thing is still not clear to me. Yesterday I found another solution to update IsPrimary (through NodeEntryRelationModelCommitter) and products got fixed, but not variations. Variations still had no primary category. Only after re-saving of the variation, it was fixed.
How does Commerce set the primary category for variations? There is no relation for it (or is?).
When it comes to node-entry relation, all entries are treated the same - so I'm not sure why you get the different behavior with variants
NodeEntryRelationModelCommitter is not something you should use directly. If you need/want to do direct manipulation of IsPrimary in your current version I suggest you resort to the ICatalogSystem / CatalogRelationDto instead.
A different behavior for variations makes no sense. Are you sure it isn't some other issue with your code, like removing and re-adding the categories after creating the variation?
NodeEntryRelationModelCommitter was a temp fix while waiting for the new Commerce version. As it was used in Service API for the same purpose, I thought that it works as expected.
Regarding variations, I did not manipulate NodeRelation directly as it is Category -> Product relations as I understand. Do variations have similar relation - Category -> Variation?
No, it's only NodeEntryRelation, for entry part it can be product, variant, package or bundle.
Ah, ok. That explains why it fixes variations only after re-saving. Then it creates the Category -> Variation relation automatically on save.