Warnings about unsupported RETURNING clause in Node SQLite3 client - sqlite

I'm using a SQLite3 database for tests in Strapi with the node-sqlite3 client. When running the tests, I'm getting the following warnings:
console.log
node-sqlite3 does not currently support RETURNING clause
at Logger._log (node_modules/knex/lib/logger.js:42:13)
Initially, I thought that it is caused by an outdated SQLite version, since RETURNING support was added in SQLite 3.35. However, I've verified that the Node client version that I'm using (5.1.4) includes a newer release of SQLite:
sqlite3#^5.1.4:
version "5.1.4"
resolved "https://registry.yarnpkg.com/sqlite3/-/sqlite3-5.1.4.tgz#35f83d368963168b324ad2f0fffce09f3b8723a7"
integrity sha512-i0UlWAzPlzX3B5XP2cYuhWQJsTtlMD6obOa1PgeEQ4DHEXUuyJkgv50I3isqZAP5oFc2T8OFvakmDh2W6I+YpA==
dependencies:
"#mapbox/node-pre-gyp" "^1.0.0"
node-addon-api "^4.2.0"
tar "^6.1.11"
optionalDependencies:
node-gyp "8.x"
To verify the SQLite version, I've ran the following query:
await strapi.db.connection.context.raw("select sqlite_version()")
As expected, it yields {'sqlite_version()': '3.40.0'}, which should support the RETURNING clause.
For the record, my locally installed version of sqlite3 (3.38.2) also supposedly supports RETURNING, but I can also confirm it is not the source of the issue: the same warnings are also displayed when the tests are ran via Docker, and the local installation does not seem to be used either way based on the sqlite_version() result.
Are these warnings something that I should be worried about, or is it just Knex warning about a possibly unsupported feature?

Related

JanusGraph 1.0.0, gremlin console getting serializer error

I have configured New JanusGraph janusgraph-full-1.0.0-rc1 on centos 7 with janusgraph-cql-es.
But when i am connecting using apache-tinkerpop-gremlin-console-3.4.8/bin/gremlin.sh
it is throwing following exception :
after remote console
> g.V();
WARN org.apache.tinkerpop.gremlin.driver.MessageSerializer - Response [PooledUnsafeDirectByteBuf(ridx: 57, widx: 57, cap: 57)] could not be deserialized by org.apache.tinkerpop.gremlin.driver.ser.AbstractGryoMessageSerializerV3d0.
java.lang.IndexOutOfBoundsException: Index 127 out of bounds for length 0
at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:372)
at java.base/java.util.ArrayList.get(ArrayList.java:459)
at org.apache.tinkerpop.shaded.kryo.util.MapReferenceResolver.getReadObject(MapReferenceResolver.java:60)
at org.apache.tinkerpop.shaded.kryo.Kryo.readReferenceOrNull(Kryo.java:834)
at org.apache.tinkerpop.shaded.kryo.Kryo.readObject(Kryo.java:684)
at org.apache.tinkerpop.gremlin.driver.ser.AbstractGryoMessageSerializerV3d0.deserializeResponse(AbstractGryoMessageSerializerV3d0.java:157)
And its also throwing error on server
08:40:45 WARN org.apache.tinkerpop.gremlin.server.handler.WsGremlinBinaryRequestDecoder.select - Gremlin Server is not configured with a serializer for the requested mime type [application/vnd.gremlin-v3.0+gryo-stringd] - using org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1 by default
08:40:45 WARN org.apache.tinkerpop.gremlin.server.handler.WsGremlinBinaryRequestDecoder.decode - Serialization error while decoding request
org.apache.tinkerpop.gremlin.driver.ser.SerializationException: The most significant bit should be set according to the format
at org.apache.tinkerpop.gremlin.driver.ser.binary.RequestMessageSerializer.readValue(RequestMessageSerializer.java:45) ~[gremlin-driver-3.6.1.jar:3.6.1]
at org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1.deserializeRequest(GraphBinaryMessageSerializerV1.java:175) ~[gremlin-driver-3.6.1.jar:3.6.1]
at org.apache.tinkerpop.gremlin.server.handler.WsGremlinBinaryRequestDecoder.decode(WsGremlinBinaryRequestDecoder.java:77) ~[gremlin-server-3.6.1.jar:3.6.1]
Need guidance on what is correct config that needs to be done, so that janusgraph works properly and i am able to access data using gremlin console.
Thanks.
Not every JanusGraph version is compatible with every TinkerPop version. The JanusGraph documentation contains a Version Compatibility Matrix which shows the versions of other project that are compatible with a given JanusGraph version. For JanusGraph 1.0, the compatible TinkerPop versions are 3.6.z. This already explains why you are having problems with Gremlin Console in version 3.4.8. Please use a 3.6.z version of Gremlin Console if you want to use JanusGraph 1.0.
Your concrete problem between these two versions is that the Gryo MessageSerializer that you are using with Gremlin Console 3.4.8 is not supported any more in JanusGraph 1.0. This problem should however go away when you use Gremlin Console 3.6 as that also does not use Gryo any more as a message serializer.
Also note that JanusGraph 1.0.0-rc1 is a release candidate for the upcoming 1.0.0 release. This means that this version is not meant to be used in production, but only to try out the upcoming release. You can of course still use it as you like, but you should expect some rough edges.

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.

Telepresence Connection Error - Traffic Manager version unsupported, must be 2.4.5 or higher while it is 2.6.5

I have started to face this problem. While trying to connect, I am facing an error stating that my traffic-manager version is 2.1.5 and it should be at least 2.4.5.
"telepresence connect" command checks for new versions and modifies it if there is any new version exists. So I am thinking that started to create a problem. Because I was using it as normal.
When I check the connector.log file these two lines create the problem.
connector/session : Existing Traffic Manager 2.6.5 not owned by cli or does not need upgrade, will not modify
connector/session : failed to connect to root daemon: rpc error: code = Unknown desc = unsupported traffic-manager version 2.1.5. Minimum supported version is 2.4.5
So somehow I have two versions now while checking for the update it hits 2.6.5 but while trying to run it tries with 2.1.5. Trying to uninstall telepresence but it also faces the same problem and I couldn't locate and delete traffic-manager 2.1.5. My OS is Windows 11.
Because of that, I am kind of blocked with my tests. Any help will be well appreciated. Thanks!
After asking the question, a new version arrived, if anyone encountered this problem, please update telepresence to 2.6.6. It is fixed now.

Airflow v2 warning No module named 'airflow.providers.mysql' despite not using this module

We recently upgraded from Airflow v1 to v2 and are currently debugging the new issues that come with such an upgrade. Currently we're getting the following warning message:
webserver_1 | [2021-08-21 18:13:45,565] {providers_manager.py:299} WARNING - Exception
when importing 'airflow.providers.google.cloud.hooks.cloud_sql.CloudSQLHook' from
'apache-airflow-providers-google' package: No module named 'airflow.providers.mysql'
I text-searched our entire project, and there are zero references of CloudSQLHook, zero references of apache-airflow-providers-google, and zero references of mysql... Because of this, we're not sure where to start with eliminating this warning message. How can we resolve this?
The Google provider has optional dependency on mysql (due to Cloud SQL using mysql as a backend). The easiest way to get rid of the warning is to install apache-airflow-providers-mysql package or use [mysql] extra when installing airflow. I also believe newer versions of airflow (quite sure 2.1+) will not log this as a warning.

virsh restore with modified xml "Error: xml modification unsupported"

I'm trying to restore an a Xen VM (domain) from state file which I create previously. At the restore I need to modify the XML of this VM with the following command:
virsh restore domU.state --xml newconfig.xml
This command triggers an error with the following text:
error: Failed to restore domain from domU.state
error: argument unsupported: xml modification unsupported
What I already try:
restore without XML, which works perfectly.
run the command with the original xml the domain was created from
run the command with a totally different file which is not even an XML
At step 2. & 3. the error output was always the same.
Used versions:
xen 4.11.1
libvirt 5.1.0
os fedora 30
As the error message suggests, the ability to pass in custom XML when restoring a guest from a snapshot, is unfortunately not supported by the libvirt Xen (libxl) driver. This feature only works with QEMU/KVM at this time.

Resources