I am using following dependency for connecting with azure cosmos db
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>azure-documentdb</artifactId>
<version>LATEST</version>
</dependency>
And using this query
"SELECT c.parentid, COUNT(1) AS count FROM collection c WHERE c.parentid != 'null' GROUP BY c.parentid"
And I am getting following error -
{"errors":[{"severity":"Error","location":{"start":91,"end":96},"code":"SC1001","message":"Syntax error, incorrect syntax near 'GROUP'."}
Is there any configuration I am missing in Java application or is group by not supported?
The problem is that you are using an old version of the Java SDK that does not have support for GROUP BY.
Please upgrade to the latest Java SDK v4. The dependency section should look like this.
<dependency>
<groupId>com.azure</groupId>
<artifactId>azure-cosmos</artifactId>
<version>4.8.0</version>
</dependency>
If you are new to using the v4 Java SDK it has both sync and async modules included. You can take a look by following this here, Quickstart: Build a Java app to manage Azure Cosmos DB SQL API data
Related
Like we use #Query for sql driver, or jpa, what is the alternative annotation for azure cosmosDB(DocumentDb) to use in the java class?
enter image description here
As i searched for spring-data-cosmosdb source code, it does not support #Query annotation. Please refer to below cases:
1.Is there any way to write custom or native queries in Java JPA (DocumentDbRepository) while firing a query to azure-cosmosdb?
2.#Query doesn't work in Spring Boot (JPA ) + Azure Cosmos db
Besides,you could ask the support of this feature in this feedback or contact with azure cosmos db team directly there.
The updated version
<dependency>
<groupId>com.azure</groupId>
<artifactId>azure-spring-data-cosmos-core</artifactId>
<version>3.0.0-beta.1</version>
</dependency>
which was released in August 2020 does support #Query.
You can find the documentation over here.
I am trying to mock the objects returning from the server to the client. So I need to deploy my Wiremock Code in Server. So is this possible or is there any other way to achieve this scenario?
And I am completely new to Wiremock. So How can I run this on JBoss?
I followed the method of running wiremock-standalone jar and I am able to capture my request and response.
But my main question is, can I able to get mock responses from #Test methods?
You could use Arquillian to test JBoss. You can test microservices using this approach and use Jboss Forge ~ another tool, to speed up the testing/dev. The start guide with Forge is here.
You will just need to add on the pom.xml the dependency for Arquillian:
<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>arquillian-weld-ee-embedded-1.1</artifactId>
<version>1.0.0.CR9</version>
<scope>test</scope>
</dependency>
To avoid any library clash you can use the standalone version of WireMock. I used it with wildly (JBoss AS) adding the following dependency:
<dependency>
<groupId>com.github.tomakehurst</groupId>
<artifactId>wiremock-jre8-standalone</artifactId>
<version>2.27.2</version>
<scope>test</scope>
</dependency>
For further information see http://wiremock.org/docs/download-and-installation/
What you've done with wiremock-standalone is very similar to what arquillian does in an integration test. You write your server code then you test it inside a container using a client extension.
Try reading the documentation at http://arquillian.org/arquillian-core/
In my java spring mvc app, I am trying to reset a bunch of records for test with Junit.
but in line:
#DirtiesContext(classMode=ClassMode.AFTER_EACH_TEST_METHOD)
It complains with:
ClassMode cannot be resolved to a variable
Update:
I have added
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<version>2.5</version>
</dependency>
but then it complains with other lines
#ActiveProfiles("test")
#Sql(scripts="requests-dataset.sql")
#DirtiesContext(classMode=ClassMode.AFTER_EACH_TEST_METHOD)
the error is:
ActiveProfiles cannot be resolved to a type
Sql cannot be resolved to a type
Sql cannot be resolved to a type
First of all, the class name is DirtiesContext.ClassMode (it's a nested class of DirtiesContext).
Second, as any other class, it must be imported.
Third, as the javadoc shows, it exists since Spring 3.0. So you won't find it in Spring 2.5. Use the same version of spring-test as the version used for the rest of the spring framework libraries that you're using.
I am trying to migrate an AppEngine project to MVM, custom runtime environment.
I faced an issue with Memcache, which was solved by replacing:
CacheManager.getInstance().getCacheFactory().createCache ...
...
with:
new XMemcachedClient(
System.getenv.get("MEMCACHE_PORT_11211_TCP_ADDR"),
Integer.parseInt(System.getenv.get("MEMCACHE_PORT_11211_TCP_PORT")))
...
(BTW, if anyone is having same issues, then maven for XMemcached is:)
<dependency>
<groupId>com.googlecode.xmemcached</groupId>
<artifactId>xmemcached</artifactId>
<version>2.0.0</version>
</dependency>
I am now facing an issue with DataStore JDO and PersistenceManager (using DataNucleus in the project).
Basically, I am looking to replace this:
JDOHelper.getPersistenceManagerFactory("xxx").getPersistenceManager() ...
...
with ?...
Are there any "magic" environment variables I can use for composing the address (like the MEMCACHE_PORT_11211_TCP_ADDR and MEMCACHE_PORT_11211_TCP_PORT is the case of Memcache)? Any other means I can communicate the datasource with (from a MVM project)?
Thanks in advance,
Ohad
You may want to consider using the gcloud-java project for accessing datastore. The big advantage here is that you can use the same code/client from App Engine, Container Engine, and Compute Engine:
https://github.com/GoogleCloudPlatform/gcloud-java
Hope this helps!
Scenario:
Existing database with one schema, the transport schema.
2 migration files where version 1 is the initial / base version. Version 2 adds a table to the management schema (but does not create that schema, I want FlyWay to do that).
Using FlyWay API (in Java application)
//...
flyway.setSchemas("transport", "management");
flyway.setInitVersion("1");
flyway.setInitOnMigrate(true);
flyway.migrate();
migration version 2 fails because the management schema has not being created. This succeeds as expected on a clean database.
I get the same problem when executing migrations via the maven plugin.
<configuration>
...
<schemas>
<schema>transport</schema>
<schema>management</schema>
</schemas>
</configuration>
...
mvn flyway:init -Dflyway.initVersion=1 -Dflyway.initDescription="Base version"
mvn flyway:migrate
Seems like if you are using FlyWay with an existing database, you then lose the ability to have FlyWay manage additional schemas.
This is currently not supported. At this point it is an all or nothing deal. Please file a feature request in the issue tracker.