Sorting issues

[ebarrenechea]

I have a list of RealmResults which I sort by a long attribute (just a timestamp). When I flip from ascending order to descending and back a few times in a row, all list items are removed from the list, except for one. Each flip will drop a few items until only one is left. Data is loaded from an unsorted query and sorting is applied after the list is loaded by calling result.sort(column, asc) on my RealmResult object.

[kneth]

Thank you for taking the time to report it. This is indeed a bug in Realm, and I have been able to reproduce it from your bug report. I have created a pull request - #456 - which fixes the bug.

[kneth]

I have merged the pull request into master, so I close the issue. @edubarr thank you for bringing up this bug :-)

[ebarrenechea]

Thanks for fixing it. Realm looks very promising! :)

[bmunkholm]

We would love to get your feedback on getting started with Realm. Anything
we can improve to ease getting started? Any features you like or miss?

On Mon, Oct 6, 2014 at 3:43 PM, Eduardo Barrenechea <
notifications@github.com> wrote:

Thanks for fixing it. Realm looks very promising! :)

—
Reply to this email directly or view it on GitHub
#453 (comment).

[ebarrenechea]

I've only had time to play around a bit with Realm, mostly simple querying and sorting. It was fairly straightforward to get started. I was already using ORMLite in my pet project and moving over to Realm was easy. One thing that I missed right away was not having auto incrementing primary keys as in SQLite. I ended up solving that by using UUIDs for my objects which required a few changes in my code. I was also caught in a issue where I was generating the UUID and setting time stamps inside my no args constructor but I later found out that my constructor code was never called. From the documentation I had the impression that only the getters and setters would be overwritten. The next thing was sorting by string fields isn't yet implemented.

As far as the project setup goes, I deviated a bit from the posted instructions. Firstly, I used the provided dependency instead of the apt plugin. The other thing was that I didn't want to have an extra module for Realm in my project so I unpacked the aar file and copied the jar file and native libraries into my module. In my opinion this is a better approach since it allows me to have different flavors per cpu architecture for my project and not package all native libs in a single apk. I think some other people would also benefit from this approach as it is simple to follow "copy these 2 jars into libs, add them as dependencies in build.gradle and copy this folder into src/main."

I still have some functionality that I need to implement since moving over to Realm but my initial impression is very good. I also like the fact that the API will be developed with feedback from the community.

Sorry for the long winded reply. Also excuse any typos, I'm writing this from my phone which turned out to be quite a challenge.

[bmunkholm]

Excellent feedback - thanks a lot!

We realize that autoincrementing keys, foreign keys etc are things you are
used to. And that's absolutely needed for making relations between SQL
objects, but not really needed for our object relations. So could you
explain what you would need it for?

We will update the docs to describe the constructor isn't needed.

Sorting will be fixed next release. We actually forgot to remove that old
limitation for certain field types. Good you mentioned it! Post a
bug/feature request whenever you experience stuff like that - then we can
fix it!

Project setup should be vastly simplified with the release yesterday! But
still if you want to leave out certain CPU architectures you still need to
remove what you don't want.

Keep the feedback coming so we can quickly get the annoyances fixed!

Thanks!
//Brian

On Mon, Oct 6, 2014 at 5:06 PM, Eduardo Barrenechea <
notifications@github.com> wrote:

I've only had time to play around a bit with Realm, mostly simple querying
and sorting. It was fairly straightforward to get started. I was already
using ORMLite in my pet project and moving over to Realm was easy. One
thing that I missed right away was not having auto incrementing primary
keys as in SQLite. I ended up solving that by using UUIDs for my objects
which required a few changes in my code. I was also caught in a issue where
I was generating the UUID and setting time stamps inside my no args
constructor but I later found out that my constructor code was never
called. From the documentation I had the impression that only the getters
and setters would be overwritten. The next thing was sorting by string
fields isn't yet implemented.

As far as the project setup goes, I deviated a bit from the posted
instructions. Firstly, I used the provided dependency instead of the apt
plugin. The other thing was that I didn't want to have an extra module for
Realm in my project so I unpacked the aar file and copied the jar file and
native libraries into my module. In my opinion this is a better approach
since it allows me to have different flavors per cpu architecture for my
project and not package all native libs in a single apk. I think some other
people would also benefit from this approach as it is simple to follow
"copy these 2 jars into libs, add them as dependencies in build.gradle and
copy this folder into src/main."

I still have some functionality that I need to implement since moving over
to Realm but my initial impression is very good. I also like the fact that
the API will be developed with feedback from the community.

Sorry for the long winded reply. Also excuse any typos, I'm writing this
from my phone which turned out to be quite a challenge.

—
Reply to this email directly or view it on GitHub
#453 (comment).

[aemeryjsa]

Jumping in to encourage the inclusion of autoincrementing keys on model objects.

If I have a data source that generates items (GPS points for example) and I want to both:
a: store these in a database, and
b: uniquely reference them

I need to assign some kind of unique id to the object. I can do this manually before inserting it into the database, but it's not uncommon to give this responsibility to the database and just use whatever id comes back as your unique reference.

[bmunkholm]

Thanks! Could you let me know what you need the unique reference for?

On Wed, Oct 8, 2014 at 4:44 PM, aemeryjsa notifications@github.com wrote:

Jumping in to encourage the inclusion of autoincrementing keys on model
objects.

If I have a data source that generates items (GPS points for example) and
I want to both:
a: store these in a database, and
b: uniquely reference them

I need to assign some kind of unique id to the object. I can do this
manually before inserting it into the database, but it's not uncommon to
give this responsibility to the database and just use whatever id comes
back as your unique reference.

—
Reply to this email directly or view it on GitHub
#453 (comment).

[ebarrenechea]

I agree that foreign keys aren't necessary with Realm since these relationships can be represented through composition. I'd argue that autoincrementing primary keys, although also not necessary, are very convenient. Without autoincrementing primary keys I have to manually assign a key to each object I create. This seems repetitive and error prone and something that could easily be handled by the persisting framework. In my case, I generated the UUIDs in my constructor, but it was never called so I ended up with no way to retrieve a specific object. I used UUIDs because it was easier, faster and simpler than creating an id generator class that would be responsible for providing the next id. In this case I'd need to take care of persisting the last used id, make sure it's thread-safe, make it available everywhere I handle writes, etc.

On the android side, many components, such as all subclasses of AdapterView and BaseAdapter, expect a numeric (long) id. It isn't necessary for those components to work and it can certainly be left out, but, once again, it's just convenient. The id is passed to click handlers and other callbacks which facilitates implementing some of these methods and makes it easier to refer to a specific item in your dataset.

[aemeryjsa]

Sure.

Assigning a unique id just means the data can be referenced elsewhere within the application (or at a later time).

Following on from the original example, if I was using an SQLite database and entering in GPS co-ordinates with an autoincremented id, I could store the id returned from the insert (in shared preferences or wherever) and retrieve the object from the database at a later stage by using the id.

I'm not sure how to do this in Realm without implementing an autoincremented property on the model myself.

[ebarrenechea]

It's a common pattern in android not to pass the object itself between activities, but to pass an identifier for the object which can be retrieved at any time. Following the GPS coordinates example, show them on a map and when the item is clicked a new activity will be started to show information about the point.

Autoincrementing ids are also very useful if you are implementing a content provider for your application. Content providers allows the use of cursor loaders and other built-in async loading strategies and is also the standard way to share data between android applications. Like I said before, not needed, but extremely convenient.