New Sqkon with metadata to support cache busting: ...

# opensource

[chrisjenx]

New Sqkon with metadata to support cache busting: https://github.com/MercuryTechnologies/sqkon/releases/tag/1.0.0-alpha02

[Pablichjenkov]

From the readme example. Is it possible to define an API where the client reifies the type when reading writing to/from the store, on the call site.
By the way, in the existing API what would happen if at the time of reading(select () in the example) I accidentally use a different type?

[chrisjenx]

Do you have an example of what you are thinking?

Also there's two options if the serializable type doesn't match right now. You can delete the row, or it will throw an exception. Can be configured by the config passed in globally or per kvs

[chrisjenx]

The select type is tied too the kvs type so generally only an issue if 1. You changed the type and didn't update the entity name. 2. You're entity changed so much that it wasn't deserializable

[chrisjenx]

Good questions. I do need to expand the readme/docs more

[Pablichjenkov]

Sure, I'm on the phone now. I will explain better later.

[Pablichjenkov]

Sorry I took a while to come back to this.
From the readme doc, this is the API to read some values from the database.

val merchantStore = sqkon.keyValueStore<Merchant>("merchant")
select(where = Merchant::name like "Chi%")
val flow: Flow<List<Merchant>> = merchantStore.select(where = Merchant::name like "Chi%")

But in a typical usage of this storage API you will have several stores. Lets say:

val merchantStore = sqkon.keyValueStore<Merchant>("merchant")
val employeeStore = sqkon.keyValueStore<Employee>("employee")

// Then accidentally

val flow: Flow<List<Merchant>> = merchantStore.select(where = Employee::name like "Chi%")

Q1: Do I get a compiler warning or some static code analysis warning at compilation time? - Indicating the field Employee::name does not belong to Merchant?
Q2: What will happen at runtime, exception or null is returned?

Then I was thinking of an API that reifies the type.

val flow: Flow<List<Merchant>> = merchantStore.select<Merchant>(where = Employee::name like "Chi%")

Notice the merchantStore.select<Merchant>(...) . I was thinking that perhaps passing the type could be used internally in select() to make sure the fields match. However, I am thinking now, that this is possible at runtime and would be inefficient.
Definitely this is something that has to be done at compilation time perhaps as a compiler or KSP plugin.

[chrisjenx]

Q1 yes, compiler warning, it is all type safe.

[chrisjenx]

Yeah it's pretty cool. Orderby is too

[chrisjenx]

And it knows the sub types of sub objects when you chain the query

[chrisjenx]

I should add more examples of that

[chrisjenx]

Look through the query tests and the keyvaluestore tests will show you some complex queries

[Pablichjenkov]

Oh that is great. Then is more than enough. Yes I really think a better Readme would help this project. I also see an open issue to return some type of Result.Success/Result.Error class. That is great!