-
Notifications
You must be signed in to change notification settings - Fork 26
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
Proper interfaces for token, client and identity objects #57
Comments
I am not sure how interfacing the data classes would help you preventing from having multiple queries. For example why couldn't caching be solved in TokenStore.
Wouldn't this solve your case? |
My issue is the conversion eating up performance for no good reason. We minimize maintenance, not development cost, and hacks are extremely high in maintenance. I am going to do a fork when i get around to optimization. |
I am confused, first you started if it is because of the amount of queries, but then it seems to be about conversion of objects. Perhaps I could help if you would have a clear example. |
The object conversion requires exposed to do additional database queries to fetch the DAO, and caching like in your example would create a security vulnerability as a token deletion from another instance would not clear the other instance's caches. Everything is simpler if you let people have implementation freedom, and interfaces are the way to go if you don't want to rework everything with generics. I wanted to see if you are interested in changing that, but it will be easier for everybody if i do a fork when i get around to optimizing the server. I will also add coroutine support while i am at it. |
To be clear the psuedo code what I provided here was just an example. To me it is still unclear what you want. Do you mean you lack some extra properties that you want to pass around with the data classes? If that is the case, I think a metadata field adds more value (like Identity then interfacing it. |
That is what i am complaining about, the Exposed DAO system requires them to be mixed and this puts me in a pickle. This decision should be up to the implementation. If you did intend this i will gladly make a fork. |
So would metadata on other data classes help you? This is something which can be done quite easily |
No, thanks. |
Is your feature request related to a problem? Please describe.
A lot of database requests can be avoided if we can use our own implementations, i get 10ms overheads every time an operation is performed, and it accumulates rapidly. With proper interfaces caching could be used.
Describe the solution you'd like
Replace the data classes
with interfaces
the data classes become the default implementation
token converters would need to be supplied to the config to avoid casting errors
Describe alternatives you've considered
shooting myself in the head because it's impossible to tiptoe around the issues as those classes are final.
The text was updated successfully, but these errors were encountered: