Sync via Servicelayer vs jalo: different results

[christoph_meyer]

Hello!

We ran into a problem with the new servicelayer based catalog sync, that does not occur when using the legacy mode. Here's the story:

• Importing a base type via impex and clearing a collection with partOf-Elements by setting an empty list

• Importing new partOf-Elements, some may be new, but some may have the same IDs than the ones deleted.

performing catalog sync via servicelayer will break:

• base item gets synced to online, collection is cleared

• partOfs are being synced, which fails because of ambiguous unique attributes for items with a preexisting code.

Apparently the partOf-items are not actually deleted or removed in time from model context when importing the base item). After the sync the old items are indeed gone but the new ones are only partially created, eg. they contain some default attribute values but have not been synced properly.

The same process using legacy sync works just fine. We can use that for now, but we cannot rely on that mode in the long term.

Am I missing something or are there any suggestions?

Cheers Christoph

[Former Member]

Hello Christoph

Remember that the Service layer have the interceptors and the Jalo layer doesn't. These are the types of Interceptors:

LoadInterceptor is called whenever a model is loaded from the database

InitDefaultsInterceptor is called to fill a model with its default values

PrepareInterceptor is called before a model is saved to the database and before it is validated by

ValidateInterceptor is called before a model is saved to the database and after it has been prepared by the PrepareInterceptor

RemoveInterceptor is called before a model is removed from the database

Maybe you had some interceptor that is causing you the problem during the sync.

Best Regads y Hope this Info help

JC

[christoph_meyer]

Yes, of course, technically it is an interceptor throwing the error. The problem is, that there should be no reason for that to happen. Somehow the item is processed incorrectly, the "old" online version is still kept in the model context, although the "new" one is in process of being synced, creating the ambiguous attribute errror.