You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the DSL doc, I can use the content class remote_id in the match section into my migration.
But, if I want execute the migration, I have this error:
Migration failed! Reason: Error in execution of step 1: ContentType can not be matched because matching condition 'remote_id' is not supported. Supported conditions are: all, and, or, not, contenttype_id, contenttype_identifier, id, identifier in file vendor/kaliop/ezmigrationbundle/Core/Matcher/AbstractMatcher.php line 37
The text was updated successfully, but these errors were encountered:
In fact, looking in the code, I see that this feature was enabled in the past, then commented out - but forgotten in the docs as 'available'.
The reason is found in a comment in the code: disallowing matches by remote_id allows us to implement KeyMatcherInterface without the risk of users getting confused as to what they are matching...
In other words: there are places where a match for a ContentType is done using a single value which can be either an integer (id) or a string (ct identifier). This is slightly different from, say, matching Contents or Locations, where matching on a single value will either look for id (for integers) or for remote_id (for strings).
The current thinking is that, if we allow to match CTs by remote_id in some places, developers might expect to be matching on remote_id by default when matching a string value, instead of matching on identifier.
Since there now seems to be at least a user who is asking for matching on remote_id, I am open to revisit this decision. A possible compromise would be to keep matching on identifier if a single string value is passed, and match on remote_id only when the user expressly asks for it - and make sure that this is well documented in the docs...
As you wish... do you need yo use the remote_id field or is identifier enough?
In my experience, usage of remote_id is only necessary when sync with a remote system is at play...
@gggeek In my case, the identifier is the same in all environment and is not used on remote system.
Well, I have solved my problem with the field identifier.
But, I like use the remote_id because is generaly it's unique.
In the DSL doc, I can use the content class
remote_id
in the match section into my migration.But, if I want execute the migration, I have this error:
The text was updated successfully, but these errors were encountered: