-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
never ending cycle, while querying #4564
Comments
@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 You mentioned the |
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. |
Thanks for the additional information, sounds like there's quite a bit of customization. Does the query work for you with the changes proposed? |
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
<#4564 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AK3XT6S4EYFYEROABOZVBRTYFWNUNAVCNFSM6AAAAAA7R44RJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRSGIYDEMBUGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@query("{profile.$id: :profileId}")
Optional findUserByProfile(@param("profileId") UUID profileId);
commenting out the query works:
//@query("{profile.$id: :profileId}")
Optional 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!
Now, it's neither accepting profiles.$id nor does return back anything
The text was updated successfully, but these errors were encountered: