Reverse lookup (Backlinks)

[tspecht]

Hi guys,

I looked at the documentation and found support for linked queries. Is reverse lookup currently possible with the java version of Realm? I'm also using Realm on Cocoa which just added support for reverse lookup and wondered if there is already support for this feature in Java.

Thanks a lot!

[cmelchior]

Unfortunately no. It is not implemented on the Java side yet, but it on our todo.

[bmunkholm]

Hi, Not yet, but it's on the task list obviously :-) We got a few other issues we intend to tackle first though. So if anyone out there can't wait and have some spare cycles, feel free to create a PR :-)

Cheers,

On Mon, Nov 24, 2014 at 12:07 PM, tspecht notifications@github.com wrote:

Hi guys,

I looked at the documentation and found support for linked queries. Is reverse lookup currently possible with the java version of Realm? I'm also using Realm on Cocoa which just added support for reverse lookup and wondered if there is already support for this feature in Java.

Thanks a lot!

— Reply to this email directly or view it on GitHub https://github.com/realm/realm-java/issues/607.

[cmelchior]

This issue has been raised a few times now, so I have begun thinking about implementations:

Cocoa uses the following method: https://github.com/realm/realm-cocoa/blob/master/Realm/RLMObjectBase.mm (linkingObjectsOfClass)

and is documented here: http://realm.io/docs/cocoa/0.89.2/#inverse-relationships

I would propose something like this in Java

public class Owner extends RealmObject {
  private RealmList<Dog> dogs;
}

public class Dog extends RealmObject {
  private String name;

  @Backlink // Simple case where relevant field is automatically detected.
  private RealmList<Owner> owners; // Returns list of all owners pointing to dog. 

  @Backlink("dogs") // Advanced case for selecting exact property if multiple exists.
  private Owner owner; // This would throw an error if more than 1 owner existed or possible just return the first?
}

The Cocoa implementation allow custom filtering of the backlinks returned, but is that a use case we should support? I lean towards no.

It would also be nice to not have to specify which property to lookup (as it is not typed). Ideally the fieldName in @Backlink is optional and automatically finds the right property if there is only one with that type. Otherwise it should be required.

[timanglade]

Can you book a time to discuss this with @alazier + me when you get close to implementing this? There are specific reasons to use the design we are using in Cocoa rather than what you are proposing — not sure all of those reasons apply to Java, but worth a chat.

[alazier]

We considered an approach similar to this in objective-c. The biggest issue with this is that there is no query support for back-links in core - so with this approach you are opening up a can of worms, where users will think they can query backlink properties like any other property even though this will not work.

Once core has support for querying backlinks like any other property I think an approach along these lines makes a bit more sense.

[cmelchior]

So you can only navigate them, not query them....that sounds odd, but yes, not being able to query on them will be a serious drawback. I wonder how hard adding querying support would be.

[tgoyne]

I don't think it'd take a lot to add support for the same queries that can be done on LinkList, but LinkList queries are currently missing quite a bit.

[ahornerr]

:+1:

http://stackoverflow.com/questions/30425398/realmresult-many-many-relationship-with-adapter

[kristjanmik]

:+1:

[jpiche]

After using linkingObjects in Swift, coming back to Java and not having this requires some workaround, especially since #1216 is still open and custom methods on realm objects aren't allowed yet. Any progress on this? I like the idea of a @Backlink annotation.

[dasheck0]

EDIT: Note that you can implement backlinks yourself see cmelchior post earlier. But it would be nice if it would be provided from Realm in the first place.

[dawidhyzy]

:+1:

[lourenci]

Is backlink not possible yet? 😔

[cmelchior]

Not yet. We are awaiting being able to query on them in the core engine before they are implemented in the Java layer.

[guillermomuntaner]

:+1: Im dealing with this issue.

I have Posts, Answer and Profile objects all of them related to a User object (think of facebook) So several Posts, Answers and Profile can have a common User (the User object is not aware and does not store this relationship). When i delete Post, Answers or Profiles, i cannot delete the User since it might be pointed by other Post, Answer or Profile.

However, if i never delete User objects, i will end up with "zombie" Users stored but not pointed by anything. I need to use something like backlinks to find and delete objets that are no longer related to anything.

BTW: If there is another logical solution or workarround let me know!

[dltlr]

+1

[juanagu]

+1

[kneth]

The proposed API for reverse lookups (backlinks) is current something like the following:

public class Owner extends RealmObject {
  private String name;
  private int age;
  private RealmList<Cat> cats;
}

public class Person extends RealmObject {
  private Cat firstCat;
  private Cat secondCat
}

public class Cat extends RealmObject {
  private String name;

  @Backlink // Simple case where relevant field is automatically detected.
  private RealmResults<Owner> owners; // Returns list of all owners pointing to this Cat. 

  @Backlink("firstCat") // Advanced case for selecting exact property if multiple exists.
  private RealmResults<Person> persons; 

  @Backlink("firstCat") 
  private Person person; // Only allow [0,1] parent objects. More will throw IllegalStateException when accessing it. 
}

// Queries
realm.where(Cat.class).equalTo("owners.name", "Diane").findAll();
realm.where(Cat.class).isNotNull("person").findAll();
realm.where(Cat.class).greaterThan("owners.@size", 1).findAll(); // This type of Query is not possible in Java yet.

Subtasks:

• [ ] Add @Backlink annotation to the annotation processor
• [ ] The byte code transformation must change the field accessor (cat.owners) to getting a RealmResults using Table::get_backlink_view() making something like cat.owners.where().equalTo("name", "John").findAll() possible
• [ ] Extend createAndValidate() to check if @Backlink does point to a proper class/field
• [ ] Extend query predicates (equalTo() etc.) to be able to query backlinks

[cmelchior]

A few additional notes:

• Swift docs are here: https://realm.io/docs/swift/latest/#inverse-relationships
• In the first version we will not be able to support a single parent reference. Mostly because we are not enforcing that when inserting objects.

[ghost]

When is this coming to Java?

[kneth]

@xenosis We are always prioritizing support and bug fixes over new features so it is a bit hard to predict ;-)

[Alex293]

Any updates on the status of backlinks ?

[kneth]

@Alex293 No, not really. We have prioritized other tasks but I hope we will be able to look at it soon.

[dasheck0]

I hope so. This is one of (if not the only one) main issues that hinders me on using Realm. It is easy to implement a workaround your self and let it be part of your database/transformation layer logic. But it is still a hassle.

[snowpong]

@dasheck0 Is it really that easy to workaround? Imagine a Tour that contains RealmList<Place>. You have many Tourand a Placecan be in multiple Tour.

Now any time a Touris changed (created, deleted or updated) we must find all affected places and update their "backlinks", and any time a Place is updated we must make sure we retain the "backlinks". It seems like a lot of work and error-prone.

Are there any actual implementations of workarounds like this in the wild you know of?

[Zhuinden]

@snowpong ...deletion of a RealmObject automatically removes it from RealmLists in other entities, and sets all entity fields pointing to that object to null in the database.

I don't see what you'd need to update when it's updated because you directly link the object.

For creation, yes, you need to set both directions of the relation.

[snowpong]

@Zhuinden Ah, of course, it might be simpler than I expected then. Thanks for the clarification.

[Zhuinden]

@snowpong To a degree. There's still no orphanRemoval (and other forms of "cascade delete") for example :slightly_smiling_face:

A deletion of an object only removes that particular object, it removes links that point to it (make them null), but it doesn't automatically remove the actual objects that point to it.

[tonny-sofijan]

Any updates on the status of backlinks?

[beeender]

@tonny-sofijan We actually released a beta version of backlink support in v3.1.0. See https://github.com/realm/realm-java/blob/master/CHANGELOG.md#310-2017-04-05

[tonny-sofijan]

@beeender: Thanks! I try to use @Backlink. Turn out it's @LinkingObjects. Oh, and could you update the realm docs so people can read the doc for this feature? Thanks.

[Zhuinden]

I think it'll be added once queries across backlinks for fields of linking objects is supported

[Vallle]

How do you initialize a field annotated with @LinkingObjects, seeing as it is required to be final?

private class ChildClass { private ParentClass parent;

@LinkingObjects("children") final RealmResults<ParentClass> parentObjects = ???; }

In my case the parent class has a field RealmList<ChildClass> making it a many to one relation.

[Zhuinden]

null.

[marchinram]

@Zhuinden do you know when queries across @LinkingObjects backlinks will be supported?

[cmelchior]

@marchinram We ran into a few issues with it, so it might not make our 3.2 release, but should definitely be part of 3.3. 3.2 will be late this week/early next week. 3.3 should be at the end of the month.

[marchinram]

@cmelchior Have queries across @LinkingObjects backlinks been added as of 3.3.1?

[cmelchior]

@marchinram Unfortunately not. We ran into a few issues. You can follow #4704 for progress (hint: It is pretty close 😄 )

[Zhuinden]

It would have been scheduled for 3.3 but the proguard issue bumped the Realm version quickly :D but it is quite close from the looks of it

[Zhuinden]

@marchinram they were merged and should be available in 3.4.0-SNAPSHOT, and I wrote an article about it as an example

[marchinram]

@Zhuinden Thanks to you and the team this looks awesome!