Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Accessing [Backlink] properties inside a query fails #2659

Open
peppy opened this issue Sep 27, 2021 · 3 comments
Open

[Bug]: Accessing [Backlink] properties inside a query fails #2659

peppy opened this issue Sep 27, 2021 · 3 comments

Comments

@peppy
Copy link

peppy commented Sep 27, 2021

What happened?

Accessing backlinks from inside a query would be expected to either throw (unsupported) or succeed, but instead it silently fails, ignoring that portion of the query and returning unwanted results.

As an aside, my goal here is to iterate over a potentially large table to truncate rows with no backlinks (while also performing external tasks). I've found that just looping over every entry in the table and checking BacklinksCount works quite well, but if there's a more performant way of handling this kind of scenario I'd love to hear it. Looping looks to take around 4s for 1m entries.

Repro steps

  • Attempt to query a property marked with [Backlink] inside an IQueryable<> realm source.
  • Note that the backlink condition is completely ignored, returning all results.

20210927 190151 (JetBrains Rider)

Version

10.5.0

What SDK flavour are you using?

Local Database only

What type of application is this?

Console/Server

Client OS and version

macOS 15 beta

Code snippets

using System;
using System.Linq;
using Nito.AsyncEx;
using Realms;
using Xunit;

namespace osu.Game.Tests
{
    public class BacklinkViaQueryBugTests
    {
        [Fact]
        public void TestBacklinkViaQuery()
        {
            AsyncContext.Run(() =>
            {
                // test with no backlinks
                using (var realm = Realm.GetInstance(new InMemoryConfiguration("a")))
                {
                    using (var transaction = realm.BeginWrite())
                    {
                        realm.Add(new TestFile { Hash = "1" });
                        transaction.Commit();
                    }

                    var filesList = realm.All<TestFile>().ToList(); // non-queryable so we can linq access BacklinksCount.

                    Assert.Equal(0, filesList.Count(f => f.BacklinksCount > 0));
                    Assert.Equal(0, realm.All<TestFile>().Count(f => f.Usages.Any()));
                }
            });
        }

        public class TestThingUsingFile : RealmObject
        {
            public TestFile File { get; set; } = null!;
        }

        public class TestFile : RealmObject
        {
            [PrimaryKey]
            public string Hash { get; set; } = String.Empty;

            [Backlink(nameof(TestThingUsingFile.File))]
            public IQueryable<TestThingUsingFile> Usages { get; } = null!; // TODO: check efficiency (ie. do we need to cache this to a count still?)
        }
    }
}

Stacktrace of the exception/crash you're getting

No response

Relevant log output

No response

@nirinchev
Copy link
Member

Unfortunately, this is not yet supported by the current LINQ engine. If you are fine with using the string-based API, you should be able to .Filter("Usages.@count > 0).Count().

@peppy
Copy link
Author

peppy commented Sep 27, 2021

I'll give that a try, thanks.

Main thing I wanted to bring up here was that it is silently ignored, which can actually cause very unexpected behaviours. Having it throw would be optimal (similar to other unsupported cases).

@nirinchev
Copy link
Member

That is indeed very surprising and I don't have an explanation for why the query engine doesn't complain about the query being unsupported. Definitely something we'll try to repro and guard against, but it'll need to wait until next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants