'msg' => 'For input string: "9223372036854775807"',
'trace' => 'java.lang.NumberFormatException: For input string: "9223372036854775807"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:583)
at java.lang.Integer.parseInt(Integer.java:615)`
On a base64 architecture, the value of PHP_INT_MAX is 9223372036854775807. This way of settings is located in lots of matcher in eZMigrationBundle and should be change to something else. Normaly 25 is the default value and should be enought for a simple matching that returns 1 row.
"Normaly 25 is the default value and should be enought for a simple matching that returns 1 row" => yes. Otoh we might use the matcher to match a lot of contents, given enough available ram ;-)
On a docker machine with on 64 bits architecture, with solr configured to optimize content search, we try to update root location id (2).
Migration file:
The issue is located in the query parameter
'rows' => '9223372036854775807'
This rows parameter is the $query->limit parameter set in the code like this in ContentMatcher: https://github.com/kaliop-uk/ezmigrationbundle/blob/master/Core/Matcher/ContentMatcher.php#L87On a base64 architecture, the value of PHP_INT_MAX is 9223372036854775807. This way of settings is located in lots of matcher in eZMigrationBundle and should be change to something else. Normaly 25 is the default value and should be enought for a simple matching that returns 1 row.