I want to be able to use bases to find notes that contain a certain text value in a property, but without having to be that exact value. It just needs to contain that text value.
A use case. I’m a farmer and have organized crops according to the time I sow them, time I plant them etc. One crop can have in its “sowing-time” property the values “1 ultimo january”, “2 february” and “3 medio march” (as a list property)
I want to be able to pull up a base with all the crops I can sow in March. If I put ‘sowing-time contains march’ then nothing comes up. If I put ‘sowing-time contains 3 march’ then all the crops come up with exactly “3 march” as one of the values in that property, but it doesn’t catch any crops with the value “3 medio march” or “3 ultimo march” etc.
Proposed solution
When using ‘contains’ bases takes that literally.
If I have notes that have a property with values like “Favourite book” and “Worst book ever” and “Unread book” and “Great movie” and I make a filter that contains “book” then I should get notes with the first three values, but not the fourth.
Current workaround (optional)
Base cannot currently do this (other users provided a workaround in this help thread). Dataview can do it, so I assume it should be simple to integrate into bases.
This is not fully correct. There is a difference between using .contains() on a list or a string. List items have to fully match the term while for strings the term must only correctly appear within the string.
With lists you can always do something like list.filter(value.contains("term")) to use the string .contains() function.
That’s great new. I’m looking at the help section for base and don’t understand all the code. I don’t know what ‘strings’ or ‘map’ means. Admidetly, most of the text on the help page you link to is impossible for me to understand.
I tried your suggestion to use list.filter(value.contains("term")) but couldn’t get it working.
Value is that what I call property and term is what I call value?
Yes, this works too as a workaround. I have used the filter note["sowing-time"].filter(value.contains("jan")) (as linked to in the thread above) and that works in the same way.
The workaround doesn’t work in all cases though. Let me give an example:
direct-sown is a property name (list)
Possible values in that property are all in a date format (2024.03.12 or 2026.05.12, for example)
I want to exclude all notes that have a value containing “2026”, ie. all crops that have been direct-sown this year.
If I make a group filter and say “None of the below applies” and then put direct-sown.filter(value.contains("2026") it doesn’t work. I’m not sure what happens but I think it excludes even all notes that contain 2, 0 and 6 somewhere in the value (like 2025.06.02 - even though that is strictly not “2026”).
I think you will also need note["direct-sown"] here, because of the hyphen.
Dates can sometimes break formulas. You can try note["direct-sown"].filter(value.toString().contains("2026")) to ensure that the value is a string type and no date type. Possibly this results in the issue you observed, because when a filter can not be evaluated for a file, it will not be excluded by your None of the below applies filter.
For me the above formula only returns values that contain 2026, so maybe give it a try.
For some reason, this doesn’t work for me. I’m copy pasting what I have in my base now so you can see exactly what it is. My language is Danish, so I’ve translated the values to English here in the thread. I’ve tried using ‘aa’ instead of ‘å’ so the problem doesn’t stem from that character either.
.filter() can only be called on a list type, not a string type. This means that one of your properties is not a list but a string type.
You can prevent the error by always ensuring that a property is a list when you call a list function. This means you should do list(property_name).filter().
Yes, you assigned the list type to this property. However, there seems to be at least one note where this is not the case and the property has a single value which is not stored as a list. Thus all filters which use a list function like filter will fail on this note.
I cannot say what exactly caused this unexpected behaviour. I have encountered it several times, so now I always ensure in my formulas to use list() before list functions, which will convert a property to list type (or do nothing if it is already a list) to prevent this error.
You’re right. I just checked and some of the notes seem to be formatted as if they are not lists in Source mode. Even though the UI makes the property appear as a list. I had to search for the YAML to find the notes. This seems like a bug. I’m not sure how to describe it.
Wonder if Linter could do something about this? Or maybe it is a bug that should be fixed in Obsidian.
Yes kind of.
The issue is not the formulas. When the value is not stored as list, I think it is valid that it returns an error.
The issue is that when converting a property from text type to list type, the frontmatter is not updated. For example, this happens when converting text to number type.
It works when you add a new list item through the UI, then frontmatter is updated. Cant say if it is a bug or missing feature.
