never ending cycle, while querying

[fssrepository]

1. it's causing never ending cycle on 3.1.5 - spring boot:

@Query("{profile.$id: :profileId}") Optional<User> findUserByProfile(@Param("profileId") UUID profileId);

commenting out the query works:

//@Query("{profile.$id: :profileId}") Optional<User> findUserByProfile(@Param("profileId") UUID profileId);

Not sure, why it's behaving in this way, but it shouldn't blow up any server!

It should override the normal behaviour as default, shouldn't be fiddling with the binding, and call itself 1M times, should throw exception!

2. the follwing syntax also was working before:

[
    {
        "$match": {
            "$elemMatch": {
                "profiles.$id": {
                    "$in": [
                        ":#{#profileIds}"
                    ]
                }
            }
        }
    }
]

Now, it's neither accepting profiles.$id nor does return back anything

[christophstrobl]

@fssrepository first of all, no matter how frustrating errors may be please keep our code of conduct in mind.

Nevertheless, thank you for reporting the issue.

Please address named parameters with :#{#...} and enclose keys in quotes, especially when using field names with special characters. Something like { 'profile.$id' : :#{#profileId} }.

You mentioned the $match expression was working before. Please provide more details (upgrading from which version,...) and take the time to provide a complete minimal sample (something that we can unzip or git clone, build, and deploy) that reproduces the problem.

[fssrepository]

2.3.0-Release to 3.1.5. In older version it was working.

I have noticed that the RestRepository is also far more restrictive, and i can't just override default behaviours in the controller or add new ones to the exact url, because it's simply ignoring it without any exception which is also a bad thing. The other bottleneck was the /**/ pattern was not allowed anymore.

I think the never ending cycle is similar to my RestRepository problem, as spring moved toward a more restrictive less error-prone approach.

I also converted the project from kotlin to java (groove/kotlin gradle) and extended the @Aggregatiom to load up from json files. I have pretty long queries to ease the pain on pagination, and make the client more lightweight.

As it was a pretty basic problem, it's quite easy to reproduce. That query i have loaded from json file in an aggregation pipeline, but i have also printed out the query in the log.

That quotes are a little bit different, as it's saved and loaded as a valid json file, not like added to an @Aggregation as a string.

[christophstrobl]

Thanks for the additional information, sounds like there's quite a bit of customization. Does the query work for you with the changes proposed? I did not yet have the time to look into the @Aggregation but will try to get to it soon.

[fssrepository]

When I commented out the @Query it was working fine.

On Wed, 22 Nov 2023, 07:46 Christoph Strobl, @.***> wrote:

Thanks for the additional information, sounds like there's quite a bit of customization. Does the query work for you with the changes proposed? I did not yet have the time to look into the @Aggregation but will try to get to it soon.

— Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-data-mongodb/issues/4564#issuecomment-1822202043, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK3XT6S4EYFYEROABOZVBRTYFWNUNAVCNFSM6AAAAAA7R44RJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRSGIYDEMBUGM . You are receiving this because you were mentioned.Message ID: @.***>