search

kaliop-uk / ezmigrationbundle

This bundle makes it easy to handle eZPlatform / eZPublish5 content upgrades/migrations
GNU General Public License v2.0
53 stars 81 forks source link

unable to use the remote_id for update content_type #220

Open jbcr opened 5 years ago

jbcr commented 5 years ago

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
gggeek commented 5 years ago

You are right.

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...

jbcr commented 5 years ago

Another answer is update the documentation because the identifier field is like remote_id (the same on each environment).

gggeek commented 5 years ago

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...

jbcr commented 5 years ago

@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.