WHAT DO YOU RECOMMEND?
- Allow a query property type. Implemented the same way as queries are now, but as a property of an object.
HOW COULD IT BE DONE?
- The exact same as queries, but injected as a property of an object
REAL WORLD USE CASES
I am building a recipe tracker. I have a recipe type and an ingredient type. I would love to be able to label an ingredient as a part of a certain recipe, then I would be able to use the query type in the ingredient and it would pull in all of the recipes that use that ingredient.
RECOMMENDED ALTERNATIVES
- I have considered something like a two way connection between types (similar to the way a two way relations in Notion), but the query thing seemed cleaner to me without the defined database structure of Notion.
Interesting idea. Out of curiosity, is there a reason why it needs to be a property, as opposed to an inline query that searches for all objects of type “recipe” that link to “This Object”?
I’m not sure I understand the need for this.
Did you know that a query can already be based on a property?
Even though the UX is poorly designed (as has been pointed out several times)
You could do it that way. I just like to see them in the UI where the list of different (in the example I gave) ingredients are. That one maybe isn’t the clearest example for that part. Maybe a better way to put it would be a project having a query property that aggregates all of the tasks and makes them viewable in the project list UI.
This is actually entirely separate from that. This isn’t querying for specific properties, this is using a specific query as a property to aggregate specific pages into a property of an object. The example I just gave where you have tasks that are tied to a specific object, then the project as a property that aggregates all of the tasks that have that project in their “project” property.
To make this more clear in general, here is a full example of what I mean:
I have a project called Make Bread
I have tasks called crack an egg, add flower, and let it rise.
Each of the tasks has a “project” property, which points to the project “Make Bread”
”Make Bread” would then have a “tasks” property. That property aggregates all of the tasks with “Make Bread” listed under the project property.
The reason I think this could be helpful is that is could work better with the Anytype system than 2-way relations do, while also being more flexible. In Notion, 2-way relations work really well, but I think that is in large part because of the structured database system that it uses. Anytype’s system is a lot more flexible in how things are contained, which could make a 2-way relation harder to implement.
Overall, I think this solves the same problem as a 2-way relation, but is more flexible and suited to Anytype’s current data model.
I see. So you don’t like the visual disparity between how a project displays its tasks and how a task can display its project(s) in your setup. Because “tasks” is a custom property that only shows up as such on projects, and there’s no way to show the reverse as a property of tasks. Well, you could by displaying the task’s Backlinks, but depending on how many ways you link objects, that might catch extra ones you don’t want to see. An inline query could give you the fine-tuned info you want, but it wouldn’t have the nice visual symmetry. Is that right?
I personally don’t need that symmetry and have been satisfied with using inline queries as described for my own projects and tasks. But I’m upvoting this anyway, because it points toward a deeper capability I would love to see. Right now, Links and Backlinks are more robust and useful than any similar custom property can be. For example, if I link from one object to another, each object appears under a property of the other: one under “Links”, the other under “Backlinks”. If every property that includes objects could likewise have a parallel reverse property for target objects, that would achieve your goal without the user having to set up queries anywhere.
There are other Link/Backlink capabilities I would like custom properties to be able to have, but that one would go a long way.
[EDIT:] Also of course inline queries don’t display on mobile, while the Link/Backlink properties do.
Thank you for your suggestion. It’s been added to our tracker and will be reviewed.
