Room Feature Request: Add Support for VIEW [67033276]

Fixed

Feature Request

Status Update

No update yet.

Description

mm...@commonsware.com

created issue #1

Sep 28, 2017 11:14AM

Component used: Room
Version used: 1.0.0-beta1
Devices/Android versions reproduced on: n/a

There appears to be no way to execute a CREATE VIEW in a way that Room will recognize. Instead, developers seem to need some icky workarounds (see

https://stackoverflow.com/q/46452786/115145 for an example).

My guess is that there should be a VIEW equivalent of @Entity, where the annotation takes the SELECT statement to go after the AS in the CREATE VIEW statement, where the Room compiler then assembles the rest.

Alternatively, @Entity could be extended to support views (e.g., via a viewSelect annotation property that triggers CREATE VIEW instead of CREATE TABLE logic). Bonus points here: there's no need to figure out the right annotation for a VIEW (since @View probably has been used 28 times already in various Android annotation processors...). :-)

Thanks for considering this!

Comments

yb...@google.com <yb...@google.com> #2Sep 28, 2017 03:16PM

Here is a leak example for a real-life use case. Again, the MediaSession was released, but the leak sticks around:

* GC ROOT android.support.v4.media.session.MediaSessionCompat$MediaSessionImplApi21$ExtraSession.this$0
* references android.support.v4.media.session.MediaSessionCompat$MediaSessionImplApi21.mSessionObj
* references android.media.session.MediaSession.mController
* references android.media.session.MediaController.mContext
* leaks com.bubenheimer.rucksack.d.q instance

an...@gmail.com <an...@gmail.com> #3Oct 8, 2017 09:12PM

Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here

https://goo.gl/TbMiIO.

fr...@gmail.com <fr...@gmail.com> #4Apr 24, 2018 04:00PM

deleted

da...@google.com <da...@google.com> Jul 24, 2018 07:53PM

Assigned to da...@google.com.

xm...@gmail.com <xm...@gmail.com> #5Aug 28, 2018 01:05PM

Can you please confirm whether this is still reproducible on API 33?

And if you happen to have access, also on the Developer Preview of API 34?

mu...@gmail.com <mu...@gmail.com> #6Sep 5, 2018 04:42PM

deleted

wo...@gmail.com <wo...@gmail.com> #7Sep 10, 2018 01:47AM

Final thing, is this a dup of https://issuetracker.google.com/220795151?

ya...@google.com <ya...@google.com> Sep 10, 2018 08:55AM

Reassigned to ya...@google.com.

ap...@google.com <ap...@google.com> #8Sep 26, 2018 12:55AM

Thanks, I believe it's a dup at this point.

The other issue was marked as fixed a year ago, but is still as reproducible as ever, I had just tested it on API 33 and UpsideDownCake DP2.

ya...@google.com <ya...@google.com> Oct 8, 2018 02:23AM

Marked as fixed.

to...@gmail.com <to...@gmail.com> #9Oct 8, 2018 03:12AM

I suppose I cannot say for sure that the two issues have the same root cause, there may be more than one cause for MediaBrowserService(Compat) leaks.

I just tested this issue here once more on my production app, on API 33 (emulator), and got a leak trace (with current LeakCanary) that closely resembles the original one I posted years ago. I let the app sit idle for another half hour, occasionally forcing a garbage collection via Android Studio Profiler, but my destroyed MediaBrowserServiceCompat (CW) instance just would not release. (I validated non-release by logging from finalize() method, which looks very reliable.)

====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

Signature: 881c4404fc048402f456764f134ed07390863849
┬───
│ GC Root: Global variable in native code
│
├─ android.os.Handler$MessengerImpl instance
│    Leaking: UNKNOWN
│    ↓ Handler$MessengerImpl.this$0
│                            ~~~~~~
├─ androidx.media.MediaBrowserServiceCompat$ServiceHandler instance
│    Leaking: UNKNOWN
│    this$0 instance of com.bubenheimer.rucksack.d.CW
│    ↓ MediaBrowserServiceCompat$ServiceHandler.this$0
│                                               ~~~~~~
╰→ com.bubenheimer.rucksack.d.CW instance
     Leaking: YES (ObjectWatcher was watching this because com.bubenheimer.rucksack.d.CW received Service#onDestroy()
     callback and Service not held by ActivityThread)
     key = 0cda35fa-fa79-4035-89ca-6ab496bd1ddc
     watchDurationMillis = 5400
     retainedDurationMillis = 392
     mApplication instance of com.bubenheimer.rucksack.d.D
     mBase instance of android.app.ContextImpl
====================================
0 LIBRARY LEAKS

A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS

An unreachable object is still in memory but LeakCanary could not find a strong reference path
from GC roots.
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 33
Build.MANUFACTURER: Google
LeakCanary version: 2.10
App process name: com.bubenheimer.rucksack
Class count: 28324
Instance count: 179717
Primitive array count: 132390
Object array count: 25025
Thread count: 39
Heap total bytes: 27055417
Bitmap count: 0
Bitmap total bytes: 0
Large bitmap count: 0
Large bitmap total bytes: 0
Db 1: open /data/user/0/com.bubenheimer.rucksack/databases/com.google.android.datatransport.events
Db 2: open /data/user/0/com.bubenheimer.rucksack/databases/rucksack-5031356898991293088.db
Stats: LruCache[maxSize=3000,hits=32348,misses=41728,hitRate=43%]
RandomAccess[bytes=1991236,reads=41728,travel=35597905162,range=32212305,size=40115227]
Heap dump reason: 1 retained objects, app is visible
Analysis duration: 16991 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-com.bubenheimer.rucksack/2023-04-25_11-53-35_598.hprof
Heap dump timestamp: 1682438042701
Heap dump duration: 4546 ms
====================================

jp...@gmail.com <jp...@gmail.com> #10Oct 9, 2018 10:32AM

I ended up letting the app sit idle for an hour, but the service still would not finalize.