In Embedded-Cassandra 3.0.3, what is the way to find if Cassandra is already running or now.
https://nosan.github.io/embedded-cassandra/#introducing
In version 2.x, there was a API getState == State.STARTED. What is the equivalent in version 3.0.3. I can't find it in the docs or examples.
There is no such thing in Embedded Cassandra 3.0.3.
If Cassandra.start() method has successfully finished it means that Cassandra is running and ready to accept connections.
Related
I'm trying to connect Mongodb with Neo4j via APOC. I get a warning of deprecation:
This feature is deprecated and will be removed in future versions.
The query used a deprecated procedure. ('apoc.mongodb.get' is no longer supported)
EXPLAIN CALL apoc.mongodb.get('mongodb://localhost:27017','dataset','Product',{PieceId:1234}) yield value
The same happens with other procedures in apoc.mongodb. I haven't found any official communication that apoc.mongodb will be deprecated, so I'm thinking that I'm doing something wrong. Any idea?
Versions:
Neo4j 4.1.2
Neo4j Desktop 1.3.8
Plugins: apoc-4.1.0.1-all.jar,
apoc-mongodb-dependencies-4.1.0.1.jar
MongoDB 4.4.0 Community
Thanks,
Francesco
We have multiple applications using mongodb as database. In our current case our applications are using the mongo driver 3.4.
On the server side currently we are running with Mongo 3.4 but we would like to keep the Mongo version up to date as long as possible.
I know that mongo drivers provide such level of backward compatibility, but I don't know whether an old version of mongo driver can work without any problem with a newer version of a mongo server.
Can mongo driver 3.4 work with 3.6 server without any problem?
Officially supported drivers provide a form of backward compatibility.
That is, newer drivers should be compatible with older server versions, but thorough testing of the application to double-check is always strongly recommended.
Note that the opposite is not always true, e.g. newer servers may be compatible with older drivers, but there is no guarantee. This is especially true if you apply setFeatureCompatibilityVersion command after a server upgrade.
The page Driver Compatibility in the documentation should be up-to-date with driver versions vs. server versions. You might be able to refer to this page in the future.
As of December 2021, the driver compatibility pages containing compatibility matrices for Python can be found at:
PyMongo: https://docs.mongodb.com/drivers/pymongo/#mongodb-compatibility
Motor: https://docs.mongodb.com/drivers/motor/#mongodb-compatibility
I trying to migrate an old application, using MongoDB 2.4 to a host, running MongoDB 3.0 in Docker container. For test purpose I am copying the data via ssh tunnel from the older to the newer version.
As I read about the updating process of MongoDB, first I should use Mongo 2.6 and then 3.0. However my test with avoiding the step with version 2.6 was successful and the database works fine. Could somebody explain me is that really possible or I have misunderstood something? It's really strange for me.
Upgrading from 2.4 to 2.6, prior to upgrading to 3.0 is a requirement according to the documentation:
To upgrade an existing MongoDB deployment to 3.0, you must be running
2.6. If you’re running a version of MongoDB before 2.6, you must upgrade to 2.6 before upgrading to 3.0. See Upgrade to 2.6 for the
procedure to upgrade from 2.4 to 2.6. Once upgraded to MongoDB 2.6,
you cannot downgrade to any version earlier than MongoDB 2.4.
Having said that, if you have run the corresponding test cases for your application, with a good test coverage, the indexes are working properly, and nothing has been broken I can not see a reason to worry about but ideally they suggest to migrate to 2.6 and then make the move to 3.0 to avoid data corruption.
We have an app that uses the C# Mongodb client lib from mongo, version 1.1.0.4184
This code currently runs against mongodb 2.6.4
We would like to stand up a new mongodb server, the current version (3.2.11). Will our code run against newer mongodb?
It really depends what you mean by "will it run". The MongoDB v1.1.0.4184 C# driver was released in June, 2011 and dates to roughly the MongoDB 1.8 server release timeframe. This driver version is certainly no longer tested or supported, and will not be fully compatible with newer server features like the WiredTiger storage engine (default in MongoDB 3.2+) or SCRAM-SHA-1 authentication (default in MongoDB 3.0+).
The MongoDB documentation includes a reference table with recommended version(s) of the drivers for use with a specific version of MongoDB: C#/.NET Driver Compatibility.
If this is a production system I would strongly recommend taking the time to update and test a supported version of the C# driver for use with MongoDB 3.2 (eg. the v1.11 C# driver). I suspect it is very likely you will encounter fixed (or novel) bugs/behaviour using a driver that is more than five years old. Your application won't be able to take advantage of many of the newer server features, and this obsolete driver predates specifications such as standard Server Discovery and Monitoring (SDAM) behaviour.
That said, assuming you aren't using any features the driver isn't aware of your code may continue to run (or at least appear to run) successfully. In my opinion doing so is a high risk deployment strategy.
Yes, i am using it, but however we have to chek on specific features, which you were using. using MongoDB latest driver is much better in terms of latest features and there are few features were removed(like 'eval()').
I have a replica set consisting of
Mongo1 2.4 primary
Mongo2 2.4 secondary
Mongo3 2.4 arbiter
Mongo4 3.0.3 secondary
My Java application uses driver version configured on all members of the replica set.
When I force a mongo v. 3.0.3 as primary the java app with driver 2.4 continue work correctly?
Concerning the part about Java driver version 2.4 and Mongo server version 3.0.3 : According to the docs it should.
But your mongo 4 will never become primary because it is an arbiter.
Kind regards
Chris
Hope it should not work correctly, or you may have some issues.
It is not a good practice to use the lower version of a java driver to use against a higher version of mongo.
Always use the right version of java driver for the mongo version.
Also, You can use it in other way, (ie) you can use a higher version of a java driver for a lower version of mongo, but ensure that backward compatibility is provided for the mongo version.
Also Having different versions of Mongo for Primary and Secondary you will be facing the backward compatibility issues.
References:
http://docs.mongodb.org/master/release-notes/2.6-compatibility/
http://docs.mongodb.org/manual/release-notes/3.0-compatibility/