search

realm / realm-java

Realm is a mobile database: a replacement for SQLite & ORMs
http://realm.io
Apache License 2.0
11.47k stars 1.75k forks source link

Is there a reason RealmTransformerTask isn't cacheable? #7858

Closed oheyadam closed 11 months ago

oheyadam commented 1 year ago

Problem

RealmTransformerTask is on the critical path for us, but it's not cacheable according to our build scans. Is there a reason for that?

Solution

Would it be possible to make this task cacheable, or is there a reason it's not?

Alternatives

No response

How important is this improvement for you?

Would be a major improvement

Feature would mainly be used with

Local Database only

rorbech commented 1 year ago

What exactly is reported to be the issue? I have tried to enable configuration caching in a sample project and it does work. Maybe related to specific versions of Gradle, AGP and realm.

Could you supply a reproducing project or try to fill in the information of the actual reported observation (stack trace, build/scan error, etc.) and the Gradle, AGP and Realm versions, etc. corresponding to the info requested in this form https://github.com/realm/realm-java/issues/new?assignees=&labels=T-Bug&projects=&template=bug.yml

oheyadam commented 1 year ago

Hey @rorbech, yea sorry my bad for not providing more information. Here's a screenshot from our build scan and you can see Gradle says this task doesn't have caching enabled. It's one of our longest running tasks as well.

We do have configuration cache enabled, and that works as you described, but configuration cache is different from the build cache. To make a task build-cacheable, you annotate it with the @Cacheable annotation. More docs here. Sorry if you're already aware of all of this, not trying to over-explain things--just thought I'd send links.

We're running Android Studio Giraffe v2022.3.1, patch 4, Gradle v8.4, AGP v8.1.4 and realm-gradle-plugin v10.16.1.

SCR-20231122-jrks
rorbech commented 11 months ago

Hi @oheyadam. It is not by design that our task should not be cacheable. Your screenshot points out that our task depends on the runtime_library_classes_jar. We are depending on the library runtime classes, since a model definition can reference classes in other modules. If some of the dependencies changes we will have to rerun our transformer. Is that the explanation you were looking for?

oheyadam commented 11 months ago

Yep, absolutely. Thank you very much!