Lookup stopped working

[Fatebreak]

I had been using a lookup field for some time to match notes for students to the lessons they attended. This had been working well for some time. After doing some work in other areas of my vault, all lookup fields seem to have stopped working. I have them set only to update manually. I tried a brand new vault and lookups worked fine. Is there any reason they would have suddenly stopped working in my main vault?

[Fatebreak]

For another test, I disabled every community plugin from my main vault except Metadata Menu and Dataview, Lookups still don't work on my main vault

[ChristinWhite]

What kind of lookups are you doing, are we talking about populating select lists or something else?

I've seen this kind of failure several times and without more information it's difficult to tailor the advice to your specific problem. Generally, when I've run into these types of issues it's happens in one of two ways:

1. There's a problem with the lookup query itself and it needs adjusted because something changed.
2. Something in my fileClass has broken and Metadata Menu is unable to resolve the issue automatically. Unfortunately, frontmatter metadata is pretty brittle.

Problem with the query

If it's problem only with your lookup query, whether it's pulling information from a select note or doing something more dynamic with Dataview it's usually turned out to be a path issue. Rename a file or folder or move something and the lookup may fail to return results so Metadata Menu has nothing to work with. If you weren't making any changes to your fileClasses something like this is most likely to be at fault.

Obsidian seems to be good at tracking and resolving changes in note names and paths. The whole [[ ]] thing is designed to be defensive about path changes by finding the most likely match in the case of multiple files being named the same thing. For renames, Obsidian usually takes note of when you do rename something and updates the other parts of the vault accordingly.

Some dataview queries are based around finding things by name, not explicit path but others expect you to be that specific so queries need updated manually. The best thing I've found for figuring what went wrong is to copy the dataview query into a note in a dataviewjs block and make sure they query is returning the information Metadata Menu depends on.

A lot of queries that you use with Metadata Menu return arrays rather and printing them, so to validate that type of query you either need to wrap the query within a dv.list(<your query>) or use a debugger; statement and inspect the object directly.

This isn't as likely to be the case if you copied things directly into another vault and the paths and names stayed the same but worked there.

Problems with the fileClass

If it's the fileClass itself it can be pain to resolve and it's pretty easy to mess it up. Well, it's pretty easy for me to mess it up anyway. Generally the issue is that one of the fields is having trouble being matched to other fields in a hierarchy or there's an inheritance conflict. If you do use object and or you extend classes these kind of issues are significantly more likely to happen. . A couple of things I've run into would include:

• You use inheritance with multiple classes, for some reason the extends class option seems to forget what it's parent is all the time so make sure those are all set correctly.
• An ID for a field was changed in one place and now the other fields related to it are unable to resolve their relationship If you use objects you have a lot of field paths that look like this: l6LlvZ____mMDcVT____pLBf31 that representing three different fields that connect in a hierarchy. One typo, moved line or something along those lines and you're in trouble. It's best not to screw with the frontmatter directly and let Metadata Menu abstract it but things can still happen.
• Another easy way to run into this issue is to change a field with child fields in an object. If you move a field that has descendants the descendants don't automatically update their path accordingly and you need to go into each field and change the parent to be correct again. See #638.
• I tried to be fancy and thought it would be a good idea to set the parent of a field in a subclass to a field in a parent fileClass. That doesn't currently work: #600.
• Another thing that tripped me up recently was not using unique names for fields. In a fileClass, you can have two fields with the same name as long as they don't share the same parent. Because of the hierarchy Metadata Menu knows they aren't the same field. However, this breaks if you have the same field name somewhere in a subclass that you have in a parent fileClass. #622.

When something like this happens it can break the entire fileClass or worse, break all fileClasses. Unless you know what you did wrong or what got corrupted in some way you may have to use a brute force solution. Deleting the fileClasses and rebuilding them usually fixes the issue. Since you're not altering the notes you aren't loosing data, just going through the pain of recreating the fileClasses.

Before your do this, make sure you know what's in the class so grab a screenshot, make a copy of the nose class and move it outside of your fileClass folder or write down what each field is and make sure you have their dataview queries and select options written down too. Start at the furthest object down the inheritance hierarchy and work your way up until you fix the problem.

Depending on how you tested your data in a different value this might have been what fixed the issue if you went about rebuilding classes or relinking parents.

@mdelobelle may be able to provide more specific or more accurate information, I'm just really,really good at breaking things so maybe I've created the same issue you're running into. 😂

[Fatebreak]

Thanks so much for the great answer @ChristinWhite! Unfortunately, I fear I somehow might have broken all fileClasses. When I made a brand new vault, I made dummy fileClasses to test the Lookup Field and it worked fine. I went to my main vault, made brand new fileClasses to mimic the dummies from the test vault and the lookup field still failed to even run. When I click the refresh button in the menu, there is no response at all, like it's not even attempting a lookup. I do not know how I may have done that or how to fix it. Besides maybe deleting metadata menu entirely and maybe starting from complete zero...

[ticmain]

I am experiencing the same issue. It surfaced when updating from v. 0.7.7 to .0.8.7

Lookups that were previously working for Select field types for example - dv.pages().where(p => p.noteType === "Goal").map(p => p.file.link) .

Have tested by rolling back to prior version, and lookups work again.

[MMoMM-org]

I have the same issue. I'm not using fileClasses atm. At a specific moment my script stopped working. It only returns null now. I have no idea atm on how to troubleshoot this.

// allows getting of a property inside a note
// does not work if the property is an array
// requires MetadataMenu

async function getPropertyValue(property, file) {
    if (typeof file === 'undefined') { 
        file = await app.workspace.getActiveFile();
    }
    console.log("Debug", property)
    console.log("Debug", file)
    let propertyValue = await app.plugins.plugins["metadata-menu"].api.getValues(
        file,
        property
    );
    return propertyValue;
};

module.exports = getPropertyValue;

[nedergaard]

I ran into an issue that may be related. When using values from a Select or Cycle "subfield" value in the 'Item display template' of an ObjectList field, nothing is displayed.

Select and Cycle uses the AbstractList.valueString method which tries to join the value. But in these cases the value is not a list, so there is no join method on the value object. This change was added in PR #585 which is a part of 0.8.7

Perhaps the AbstractList.valueString method should check whether the value is an array or not, like AbstractList.displayValue does?

[bhemmelgarn]

I have also encountered this issue. It's not that lookup is completely broken, but that it only works for discrete list items. For example in frontmatter:

attendees: 
  - "[[Dave]]"
  - "[[Beth]]"
  - "[[Shawn]]"

Inline, the only compatible workaround seems to be listing them discretely like so

attendees:: [[Dave]]
attendees:: [[Beth]]
attendees:: [[Shawn]]

So for example, attendees:: [[Dave]], [[Beth]], [[Shawn]] is broken, as well as attendees:: [[Dave]] came and said that he had a great time!

My use case for lookup generally has text entry around the link, troubleshooting the lookup is what brought me this far. I think there would be a way to do a workaround with a Formula that .file.attendees.contains(dv.current()) but I'm not actually JS fluent and can't quite crack that one. Regardless, it would be great to have Lookup able to find those links around other text

[sdkasper]

Similar issue here. I have a fileClass with a "multi" select field based on a query:

dv.pages('"01 Projects/Travel/Accommodation"').map(page => [page.file.name])

The path is correct, there are notes in the folder. If I run the query inline in a note like so

$=dv.pages('"01 Projects/Travel/Accommodation"').map(page => [page.file.name])

I get the expected results. But when creating a new note based on that fileClass and clicking on the dropdown arrow, I get an empty dialog box.

This applies to all the fields based on such queries and causes major issues. Any ideas, how to solve this yet?

Metadata Plugin: 0.8.7 Obsidian: 1.6.3