In-Memory Support?

[ScottPierce]

A full in-memory / non-persistent implementation could be very useful for testing and for complex caches.

I don't see anything in the documentation indicating this is currently a feature.

[greenrobot]

This is not currently supported. Typically you would set up something like this for testing:
https://github.com/greenrobot/ObjectBoxExamples/blob/master/desktop-test-example/src/test/java/AbstractObjectBoxTest.java

Performance should not be an issue.

[ScottPierce]

If there was an in-memory implementation, I'd likely try to use it as an object graphed cache. This could potentially be very useful for that.

[greenrobot]

Some simple object cache doesn't do the trick?

[ScottPierce]

The reality is most servers I've worked on have multiple endpoints that return different sets of the same values represented in the server database. You end up with duplicate data in your cache in multiple places, and it's very difficult to invalidate everything properly. An in-memory version of ObjectBox could work very well for handling a more complex cache.

Netflix has a good example on their blog of the non-open source Android implementation of the cache they built to work with their falcor server library.
http://techblog.netflix.com/2015/10/falcor-for-android.html

To be clear, I think other people would find other useful ways to use the in-memory implementation as well.

[greenrobot]

Sounds like an interesting idea, but I didn't get it fully. We are talking only about what happens on the Android client, right? Why wouldn't you just persist what you get from the server and rely on ObjectBoxes caching? You can get objects at a rate of ~100k/s. I am asking to understand (I am not familiar to Falcor). Maybe an example would also help.

[ScottPierce]

This json model represents the idea pretty well in json form.

{ 
    "topVideos": {
        // List, with indices
        0: { $type: "ref", value: ["video", 123] }, // JSON Graph reference
        1: { $type: "ref", value: ["video", 789] }
    },
    "video": { 
        // Videos by ID
        123: {
            "name": "Orange Is the New Black",
            "year": 2015,
            ...
        },
        789: {
            "name": "House of Cards",
            "year": 2015,
            ...
        }
    }
}

An endpoint form the server gives you the top videos. So you store the videos in the topVideos key. But there are multiple other endpoints that return videos that you want to cache. So instead of caching the video data in topVideos, you cache it in video, and store references in topVideos to the data stored invideo.

This is advantageous because now you can call other endpoints that return video data, and cache it in the same manner. You could call the "all videos" endpoint, and cache it's data in a similar way, storing the actual data in the video key, and a reference to the data in the allVideos key. All the data is stored in a single place, meaning you don't have multiple copies of the data in different keys, and also you don't have old copies of the same data in different places, assuming the data changes.

[greenrobot]

Going in memory will be a rather expensive change.