Upgrading Doctrine Migrations - symfony

I am getting this warning on my codebase, here's my composer
Package zendframework/zend-eventmanager is abandoned, you should avoid using it. Use laminas/laminas-eventmanager instead.
So I needed to upgrade Doctrine Migrations bundle, but I can't seem to upgrade it, and I can't find an upgrade log.
First I get errors about Doctrine\DBAL\Migrations\AbstractMigration, so I replaced them all to Doctrine\Migrations\AbstractMigration. Now I'm getting
Compile Error: Declaration of Application\Migrations\Version20170927104049::up(Doctrine\DBAL\Schema\Schema $schema) must be compatible with Doctrine\Migrations\AbstractMigration::up(Doctrine\DB
AL\Schema\Schema $schema): void
I asked for a CHANGELOG https://github.com/doctrine/DoctrineMigrationsBundle/issues/296
But anyhelp would be greatly appreciated

The error tells you your function is not compatible with the abstract function, did you forget to add the return type to your function?
make it:
public function up(Schema $schema) : void
{}

You should start by upgrading your packages through composer upgrade - for example, in your composer.lock, you are using ocramius/proxy-manager in a version of that bundle that is nearly three years old, and this requires the abandoned package. The name change from zendframework/zend-eventmanager to laminas/laminas-eventmanager has happened in 2019.
A next step might be to upgrade the constraints such that you require even newer packages. For example, there are much more recent versions of doctrine/doctrine-migrations-bundle or symfony/swiftmailer-bundle, and updating them from time to time helps to avoid problems. As the gap between the installed version and a more recent version gets larger and larger, the upgrading process gets more complex too.
On the other hand: if your code is still working properly, you can simply ignore that warning. It tells you that the given package will not receive any updates after all, but that does not mean you are in danger immediately

Related

Bit.dev error creating a component dur to package mismatch

I have an issue and it wont let me create a component because of mismatch versions, I tried deleting vue-loader, vue-template-compiler node modules. Deleting #vue/compiler-sf an reinstalling etc and i always get the same message.
new components
(use "bit tag --all [version]" to lock a version with all your changes)
> test-test ... issues found
error found while parsing the file (edit the file and fix the parsing error):
src/components/testTest.vue ->
Vue packages version mismatch:
vue#3.2.31 (C:\Users\Alex 2019\AppData\Roaming\npm\node_modules\vue\index.js)
vue-template-compiler#2.7.13 (C:\Users\Alex 2019\AppData\Roaming\npm\node_modules\bit-bin\node_modules\vue-template-compiler\package.json)
This may cause things to work incorrectly. Make sure to use the same version for both.
If you are using vue-loader#>=10.0, simply update vue-template-compiler.
If you are using vue-loader#<10.0 or vueify, re-installing vue-loader/vueify should bump vue-template-compiler to the latest.

Conflicting constraints in Airflow constraint file

For setting up AWS MWAA with snowflake, as per the AWS documentation here, I created a requirements.txt file with following content:
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.2.2/constraints-3.7.txt"
apache-airflow[snowflake]
This worked successfully. Next I wanted to add dbt to my eco-system and updated my constraint file to:
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-2.2.2/constraints-3.7.txt"
apache-airflow[snowflake]
dbt-core==1.1.1
dbt-snowflake==1.1.0
Now this is where things start breaking. I get the following error when I build this-
ERROR: Cannot install snowflake-connector-python[secure-local-storage]==2.7.0 because these package versions have conflicting dependencies.
The conflict is caused by:
snowflake-connector-python[secure-local-storage] 2.7.0 depends on keyring!=16.1.0 and <22.0.0; extra == "secure-local-storage"
The user requested (constraint) keyring==23.2.1
This seems really weird since both versions: snowflake-connector-python 2.7.0 and keyring==23.2.1 are enforced in the airflow constraint file itself: https://raw.githubusercontent.com/apache/airflow/constraints-2.2.2/constraints-3.7.txt
It is highly unlikely that airflow constraint file is incorrect. Am I missing something here?
Yes, I guess there are some inconsistencies and version conflicts. What I ended up doing is copying all libraries from constraints.txt to requirements.txt, removing unused libraries and run ./mwaa-local-env test-requirements to check for inconsistencies.
Then I manually changed versions of all version conflicts.

Codeception\Test\Test::run(?\Framework\TestResult $result = NULL) must be compatible with

PHP v7.2.3
PHP Unit 8.2.3
Codeception 3.0.2
When I try to run tests I get the following error:
Declaration of
Codeception\Test\Test::run(?PHPUnit\Framework\TestResult $result =
NULL) must be compatible with
PHPUnit\Framework\Test::run(?PHPUnit\Framework\TestResult $result =
NULL): PHPUnit\Framework\TestResult in
/var/com/vendor/codeception/codeception/src/Codeception/Test/Test.php
on line 18
When I look at the definition of PHPUnit\Framework\Test::run I see it specifies a return type but Codeception\Test\Test::run does not and this would appear to be the problem.
I've checked back through the version history of both of these files in the respective git repos and it seem these files have been this way for many versions.
After much searching it doesn't seem anyone else has posted the issue which makes me think I'm missing some key insight.
Any light shed on this issue would be much appreciated, thanks!
In the end a fresh install of Symfony latest version and Codeception presented a working solution.
Since this was initially a port from another symfony 3 application (with an older version of codeception) it's likely that there was a misconfig or incompatible package.
The other possible cause which occurred to me later is that the cli for codeception in previous versions of symfony was run from a general bin directory 'bin/codecept' and now we run directly from 'vendor/bin/codecept' its possible that my CI script was referencing an outdated cli.

About ROS_RMPT_SLAM package compiling issue

While doing catkin_make ROS_MRPT_SLAM, I got following error
In file included from /usr/include/mrpt/base/include/mrpt/utils/CFileGZInputStream.h:12:0,
from /home/ian/catkin_ws/src/mrpt_slam/mrpt_ekf_slam_2d/include/mrpt_ekf_slam_2d/mrpt_ekf_slam_2d.h:11,
from /home/ian/catkin_ws/src/mrpt_slam/mrpt_ekf_slam_2d/src/mrpt_ekf_slam_2d.cpp:7:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h: In member function ‘void mrpt::utils::CStream::WriteVariant(T)’:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h:313:15: error: use of ‘auto’ in lambda parameter declaration only available with -std=c++14 or -std=gnu++14
t.match([&](auto& o) { this->WriteObject(o); });
^
/usr/include/mrpt/base/include/mrpt/utils/CStream.h: In lambda function:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h:313:45: error: no matching function for call to ‘mrpt::utils::CStream::WriteObject(int&)’
t.match([&](auto& o) { this->WriteObject(o); });
I guess it's compatibility matter or something because there were missing header files and so on.
This is the ROS_PACKAGE wiki: http://wiki.ros.org/mrpt_slam
And I just followed instruction from official MRPT website.
If the developer or anyone who is familiar with mrpt toolkit sees this question, may I get some advice about these errors?
By the way, I installed mrpt toolkit using the following website's instruction: http://www.mrpt.org/MRPT_in_GNU/Linux_repositories.
I'm the main author of MRPT and of part of the ROS packages.
Sorry for the mess, but you found us in the transition between the mrpt series 1.5.* and a new mayor rewrite based on C++14 which currently is published in git as mrpt 1.9.9 and eventually will be released as 2.0.0.
This transition must be propagated to the ros nodes, but so far we have upgraded mrpt_navigation only, mrpt_slam is in the to-do list.
So: a solution is to install an mrpt version of the 1.5.* series, and to build the ros packages from sources, paying attention to checking out the branches named compat-mrpt-1.5.
Hope this helps!

Neo4j spatial server plugin fails on withinDistance and closest java.lang.NoClassDefFoundError

I know that the plugin is being loaded properly, as other methods work such as spatial.procedures and spatial.addNode etc.
The error results after a call like this:
CALL spatial.withinDistance('profile_geo', [43.524, 96.7341], 500)
and the error that results is this:
Failed to invoke procedure `spatial.withinDistance`: Caused by: java.lang.NoClassDefFoundError: org/neo4j/cypher/internal/compiler/v3_0/commands/expressions/GeographicPoint
The same error appears when trying to use the closest function as well. Any help would be appreciated.
It looks that you are missing required Jar for GeographicalPoint class.
Please make sure you have this class in your Jars. I know this class exists in neo4j-cypher-compiler-3.0-3.0.3.jar but it is not going to work for you as it is residing in different namespace. If you will not be able to pinpoint the corresponding Jar in your environment please have a look at Maven repository and try to find it there.
short answer: upgrade to 3.0.3 (both neo4j and plugin)
long answer:
I ran into the exact same issue today. I was running version 3.0.2 with server plugin version 3.0.2 and ran the cypher query:
CALL spatial.withinDistance("spatial_records",{lon:20.0,lat:50.0},100000000)
Joran mentioned in the comments above that the REST API was a working alternative. So I tried that out and found he was indeed correct.
I tested this using httpie, with the following command:
cat tmp.json | http :7474/db/data/ext/SpatialPlugin/graphdb/findGeometriesWithinDistance
where tmp.json looks like:
{"layer" : "spatial_records","pointX" :3.9706,"pointY" : 46.7907,"distanceInKm" :10000000000}
While this works, using CYPHER with stored procedures would be nice. So upon further investigation, I noticed that a recent commit contained the following changes:
- <neo4j.version>3.0.1</neo4j.version>
+ <neo4j.version>3.0.3</neo4j.version>
...
-import org.neo4j.cypher.internal.compiler.v3_0.commands.expressions.GeographicPoint;
+import org.neo4j.cypher.internal.compiler.v3_0.GeographicPoint;
So I ended up downloading version 3.0.3 of both neo4j and the spatial plugin. Whatever the issue was before, seems to be fixed in this version. The call to the stored procedure now works as expected!

Resources