-
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
KTOR-1264 - Add UUID to DefaultConversionService #2188
Conversation
I remember we already had similar PR in the past. The problem with UUID is that it is JVM-only. Once one starts using it on the server, it appears to be logical to have it in client. However, in the client, it only works on JVM but not on iOS. So it's preventing seamless porting. |
@cy6erGn0m Yeah, working on a MPP with UUID (not only ktor, but exposed etc also) is very annoying, until Kotlin will finally have a common UUID implementation... |
Ok, let me see if we can add our own UUID at some point. I need to investiage the problem and measure costs and risks. |
Here is a very simple UUID4 implementation using
|
Still a lot of open questions anyway:
When introducing such a basic type, it is always difficult because it's not enough to just ad-hoc it, you need to design it 😞 |
So, the first question: why do you need it? What is your use-case, why don't you use regular String and why it is so boring so that you made this PR? How do you use UUID:
|
Thank you for your feedback! One basic use case is a multiplatform application, eg a Todo service. The main advantage using UUID over an Integer as the identifier is the possibility creating a new Todo offline without sync conflicts. Because a UUIDv4 is "unique", the probability having the same UUID in your application scope is extremely low (see https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions). You can upload this local generated id directly without problems to you server and store them in the server DB. The CloudKit framework by Apple uses this advantage. Creating a UUID:
Compareable, hashable: Support for other UUID versions: Serialization: Absolute, it is way lot more difficult to design this "simple" class for public use with binary compatibility than implementing a UUID class in a non-public project without binary compatibility, which needs only UUIDv4 :) I would love to see a UUID implementation in the Standard lib instead in Ktor! (https://youtrack.jetbrains.com/issue/KT-43042) But unfortunately a UUID is still not implemented in the std lib. Back to the initial "problem" of this pull request :) operator fun Parameters.getValue(receiver: Any?, property: KProperty<*>): java.util.UUID =
UUID.fromString(get(property.name)) I simple created this PR because in ConversionService you already have JVM only types. |
@hfhbd See https://github.com/cy6erGn0m/kotlinx-uuid for prevew |
@cy6erGn0m WOW! I did not see coming this so fast. |
@hfhbd Remember that it's not even a real kotlinx library: it's not under the organization and it's status is undecided yet. I am planning to publish it to a separate bintray repo next week but I can't guarantee anything else for now. |
@hfhbd added exposed support to the library |
@cy6erGn0m Thanks! I did try to use it with my playground/experimental app ComposeTodo, and releasing the artifacts would be super. |
@rsinukov Rebased on |
Good job, thanks! |
Co-authored-by: hfhbd <hfhbd@users.noreply.github.com>
Co-authored-by: hfhbd <hfhbd@users.noreply.github.com>
Subsystem
Server-Core, JVM, DefaultConversionService
Motivation
Add UUID to DefaultConversionService - https://youtrack.jetbrains.com/issue/KTOR-1264
Solution
Added UUID