Update deps and migrate from okio to kotlinx.io #112
Conversation
|
Temp repo: maven {
name = "worldmandiaRepositoryReleases"
url = uri("https://repo.worldmandia.cc/releases")
}implementation("io.github.xxfast:kstore:0.8.0") |
| import kotlinx.serialization.Serializable | ||
| import kotlinx.serialization.SerializationStrategy | ||
|
|
||
| public abstract class KStoreFormat<T : @Serializable Any>(public val serializer: KSerializer<T>) { |
There was a problem hiding this comment.
Is there a reason why we need this intermediary class instead of passing in the serialiser directly?
There was a problem hiding this comment.
Not all formats support KotlinX.IO
There was a problem hiding this comment.
Hello.
It would be premature to support custom serializers, becouse kotlinx.serialization is currently stable with only the Json serializer.
It may be possible to use a protocolbuffers/protobuf serializer like Jetpack DataStore, but is that level of customizability necessary?
In any case, support for custom serializers is not important when migrating from Okio to kotlinx.io, so this should be considered in a new pull request.
There was a problem hiding this comment.
as before you do not need to change this, since there is a JSON serializer, this is simply done if you really need to change this, kotlinx.io allows you to convert this to java bytearray and/or string
There was a problem hiding this comment.
as before you do not need to change this, since there is a JSON serializer,
I see there are no breaking updates on this.
I see there are no breaking updates on this, except for argument name changes such as kstore.file.storeOf.
this is simply done if you really need to change this, kotlinx.io allows you to convert this to java bytearray and/or string
I don't see any reason to bother writing your own EncodeToSink to encode to a Java ByteArray and/or String. Wouldn't Json encoding be enough?
For large datasets, ProtoBuf is a good choice, but as I mentioned in the previous comment, kotlinx.serialization's ProtoBuf is not stable. Google's protocolbuffers/protobuf is stable but only supports the JVM.
It should remain simple and tiny without adding unnecessary customizability, I think.
In any case, support for custom serializers is not important when migrating from Okio to kotlinx.io, so this should be considered in a new pull request.
There was a problem hiding this comment.
Yeah prolly best if we do this separately - and I agree we would need some abstraction to handle multiple formats, but we will cross that bridge when we get there
|
Looks like CI is failing
I will fix these in my branch |
| kotlinx-serialization = "1.6.2" | ||
| okio = "3.9.0" | ||
| junit-jupiter="5.10.1" | ||
| kotlin = "2.0.20-Beta2" |
There was a problem hiding this comment.
Hi @mani1232 is there a reason why we can't use the latest stable?
|
Included in #116 and available on 0.9.0-SNAPSHOT |
No description provided.