Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unable to use the remote_id for update content_type #220

Open
jbcr opened this issue Aug 8, 2019 · 4 comments
Open

unable to use the remote_id for update content_type #220

jbcr opened this issue Aug 8, 2019 · 4 comments
Milestone

Comments

@jbcr
Copy link

jbcr commented Aug 8, 2019

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
Copy link
Member

gggeek commented Aug 9, 2019

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
Copy link
Author

jbcr commented Aug 12, 2019

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

@gggeek
Copy link
Member

gggeek commented Aug 12, 2019

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
Copy link
Author

jbcr commented Aug 13, 2019

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

@gggeek gggeek added this to the 6.0 milestone Aug 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants