I would like to use PagingAndSortingRepository with spring-data-jdbc but it not seem to work. It's only available with JPA ?
I tried to use PagingAndSortingRepository and use the findAll(Pageable pageable).
But I actually get a "No query specified on findAll"
2020 Update
Support for PagingRepositories was introduced at version 2.0.0.M3 (2020-02-12).
Spring Data JDBC Changelog
PagingAndSortingRepository is supported since version 2.0 M3
That version wasn't available when this question was asked.
Original answer
Yes, you are right, pagination isn't ready yet.
There is actually a PR that will create infrastructure for that but it won't enable the feature yet. For that you should watch https://jira.spring.io/browse/DATAJDBC-101.
Related
what is the easiest way to map POJO to/from PostgreSQL user-defined types?
Wait until Hibernate 6.2 is released. This will happen soon (within 2022) and will come with support for mapping embeddables as structs. Also see https://hibernate.atlassian.net/browse/HHH-15327
I'm using Spring Boot and am trying to figure out how I can see a list of all the default properties for the MongoDB connection.
I looked at AbstractMongoClientConfiguration but it's abstract and I can't see where the defaults come from. Looking at the class hierarchy for this class I can't see any default implementation in the Spring libs I have.
Where are the defaults for this connection? I don't see any properties files either, but might be missing them.
Had the same issue not too long ago. The official spring-data-mongodb documentation doesn't really mention any details about connection properties and their default values.
However, you can find more detailed information about the connection parameters in the MongoDB Java Driver Documentation and even more detailed in the Connection string docs including some default values.
Spring Data MongoDB uses default values generated by calling the builder method for MongoClientSettings.
I'm using Akka Persistence, with LevelDB as storage plugin, in an application written in Scala. On the query-side, the current implementation uses PersistentView, which polls messages from a PersistentActor's journal by just knowing the identifier of the actor.
Now I've learned that PersistentView is deprecated, and one is encouraged to use Persistent Query instead. However, I haven't found any thorough description on how to adapt the code from using PersistentView to support the preferred Persistence Query implementation.
Any help would be appreciated!
From the 2.4.x-to-2.5.x migration guide:
Removal of PersistentView
After being deprecated for a long time, and replaced by Persistence Query PersistentView has now been removed.
The corresponding query type is EventsByPersistenceId. There are several alternatives for connecting the Source to an actor corresponding to a previous PersistentView actor which are documented in Integration.
The consuming actor may be a plain Actor or an PersistentActor if it needs to store its own state (e.g. fromSequenceNr offset).
Please note that Persistence Query is not experimental/may-change anymore in Akka 2.5.0, so you can safely upgrade to it.
I'm trying to have a geo-pagination system.
I refeer to this article
Blog article from mongoDB
My problem is that I'm using doctrine MongoDB and i don't seem to find how to set minDistance field in Doctrine MongoDB
My Mongo version is 2.4.8
Support for this was not implemented in Doctrine MongoDB, but I've implemented it in PR #171, which is now in the 1.2.x-dev branch (we don't yet have a 1.2.0 release). You can look at the documentation blocks or unit tests in that PR for insight into how to use it, but I modeled it after maxDistance().
I should mention that in 1.1.x of Doctrine MongoDB, you didn't actually need the builder method available to inject the minDistance option into geoNear. If you look at this code in Query.php, you'll see that we merge options from the builder atop $options, which ultimately comes from Query's constructor. Keep this in mind should you need to pass options to other commands when there is not a pre-existing builder method.
Lastly, you mentioned that you're using MongoDB 2.4.8. Note that MongoDB 2.4.x does not support this option (for geoNear) or query operator (for $near and $nearSphere). It was implemented in SERVER-9395 (this commit) and first appeared in 2.5.1. You'll also find it in 2.6.0, of course.
Okay, after much struggle, I just got my project upgraded from Breeze 1.2 to 1.4 and EF 5.0 to 6.1 and it's running. However, I noticed, some of the queries don't work anymore. On client, I got error like this:
GET
.../breeze/breeze/Methods?$filter=Id%20eq%201&$expand=CompoundSettings%2FCompound%2FTargetPeaks
400 (Bad Request)
As I read, some people report that breeze doesn't support many-to-many relationship. However, mine is not a many-to-many.
In my case, Methods contains a collection of CompoundSetting, which contains a Compound, which contains a collection of TargetPeak. I also tried to remove virtual keyword for collection, but it doesn't seem to make any difference.
If the expand doesn't include the last TargetPeaks, it works.
What's the problem? Too many nested layers? Please note the same query (with even more layers) worked fine in Breeze v1.2.
I think you might be having the problem described in this SO post.
Older versions of EF and WebApi did not support $expand, so the Breeze EF server code used its own implementation for $expand. Now, with WebApi 2, Breeze uses Microsoft's implementation, which uses Microsoft's defaults.
The Queryable attribute includes a "MaxExpansionDepth" property, to prevent clients from being able to make too large a query. I'm not sure what the default is, but try:
[BreezeQueryable(MaxExpansionDepth = 4)]
public IQueryable<Method> Methods()
{
...
}