Why is this crashing with `Property klass should b...

# exposed

[Stephcraft]

Why is this crashing with Property klass should be initialized before get. ?
When the uuid property of the Profile DAO is accessed here? Thanks.

class Profile(id: EntityID<UUID>) : Entity<UUID>(id) {
    companion object: EntityClass<UUID, Profile>(ProfileTable) 

    var uuid by ProfileTable.uuid

    init {
        transaction {
            val playerRecordCount = PlayerRecordTable.selectAll().where { PlayerRecordTable.playerUUID eq uuid /* <- here */ }.count().toInt()
        }
    }
}

Caused by: java.lang.IllegalStateException: Property klass should be initialized before get.
	at kotlin.properties.NotNullVar.getValue(Delegates.kt:62)
	at org.jetbrains.exposed.dao.Entity.getKlass(Entity.kt:48)
	at org.jetbrains.exposed.dao.Entity.setValue(Entity.kt:231)

[AdamW]

What are you trying to achieve? This looks very fragile even if it worked.

[Stephcraft]

Computing aggregated data related to the DAO Entity

[AdamW]

Any reason not to use UUIDEntity & UUIDEntityClass here?

IMO you should compute aggregated data in a repository and keep the entity ”stupid”. Here the initializer runs when Exposed tries to construct the entity via reflection, which blows up.

If you’re sure you want such fields in your entity, then you should do it via a computed field or by setting up references between these two tables. See here and here

[Stephcraft]

That's what I ended up doing. I didin't know about UUIDEntity & UUIDEntityClass . Better practice to use these probably?

[AdamW]

Yup 👍

[Stephcraft]

I'm building a leaderboard system with different filters, right now what I'm doing, is everytime there is a new enty posted to the db I query all possible filtered leaderboard views (time based, player count, etc) all top 10 results. Sometimes these leaderboards require aggregated data, for instance all player scores combined. Is there any way I could improve caching here? Like only recompute the leaderboard views if the new entry would get in the top 10. Or does this sound like over optimization? I know this is off topic from the main question, but I appreciate any pointers if you got some for such a system.

[Stephcraft]

Also, related to the leaderboard, it would be nice to have all unique entries per player, right now my leaderboard shows (player, score), but it would be nice to distinct by player & score. There's distinctBy() but that's a Kotlin function, and withDistinct(), but it does not allow to specify a set of columns. I know somewhat a way around this, but if you know of the best way to go about it with DAO, let me know.

[Stephcraft]

Also what do you mean by 'repository' actually? I've gone the computed field route

[AdamW]

As in just using DSL for anything complex. I hope DAO is ironed out for 1.0 😅

[Stephcraft]

Haha yeah

[AdamW]

I’ll take a deeper look at the questions a bit later, but what’s your current setup like? EntityHook?

[Stephcraft]

I didin't look into EntityHook, but I know when I post a new entry, so I update all aggregated data then.

[AdamW]

So it’s hard to say if caching is premature here, but caching the views and explicitly invalidating when something changes sounds simple. If needed, you can then optimize the invalidation condition(s) as you see fit.

In any case I would keep it far, far away from the DAO side of things and use DSL for the heavy lifting. Is your project in a public repo?

[Stephcraft]

Its a private repo, if you'd like we can do a short call on discord or other to share ideas. My discord is: @Stephcraft