Sorry for the late reply, been a busy week for me. Yeah, I’ve been using this implementation, but I would like to be able to use a universal “Related To:” field and limit the object types to select based on the type of the object the relation is selected from. This way you can organize all the “Related To:” relations easily and connect them together, the graph view would be way better this way as well.
I just stumbled upon your dilemma here. I tried something similar for workouts but with collections. To learn some of the program’s capabilities, I used collections to create a daily log of exercises. Within the daily log collection I have a running object type, a jogging object type, etc.
I manually add the types to the collections database every day when I work out, but limit the view to the past week through the current day. That way the list stays short. The collection includes relations for time and distance, location, date, workout notes, the type of exercise, etc. The relation for the type of exercise links back to its object type page (e.g., running).
The page for running would include my running shoes, other relevant info, and an inline collection that filters my daily log of exercises database to just running. Every time I create a new running workout entry into my main daily log collection, the relevant running workout populates on the inline collection on the running page. There are no date filters on that collection, so I will let it grow long for now.
Hope that’s not too confusing. Not sure if that approximates the capabilities you reference in Notion, but it does reveal the power behind collections in Anytype. They are much more powerful than sets. I look forward to seeing collections develop further.
I am sorry but I think I didn’t fully understand your setup. Can you include some screenshots as how it works?
I created a homepage Fall 2023 and placed the inline collection Exercise Tracker here. I created a date filter to only show exercises from the past week. That way the list stays short:
As you can see in the screenshot, the Exercise Tracker collection currently has two exercise object types: Running and Walking. I will add others such as Strength Training, etc.
The Running Page also has the inline Exercise Tracker collection, but it is filtered to just running object types, and it grows automatically whenever I add a running workout to the collection. (I add workouts to the collection on my Fall 2023 homepage every day.) This list on the Running Page will continue to grow since I will not add a date range filter. I also add other info relevant to running such as running shoes:
Hope the screenshots help.
Thanks for the extra information. Let me see if I get it right; you create running objects for specific days, right? I mean you must have multiple objects in your library with the same name: “running” with different “creation date” s, right?
I think of them as running page “entries” for a specific day, which could be everyday, if I run everyday. (Same goes for the other object types like Strength Training in the collection.)
I conveniently create a new entry on the inline collection on my custom homepage, often with a custom title like Evening Run. So they don’t all say “running.” Should I ever feel the desire to add further notes on a specific entry, I can open up an entry, and add notes, to complement any info already in the relations.
The only page I have that is labeled Running is the “Running” page I set up in the screenshot I posted. That’s the page that appears under the Exercise relation.
In grid view, the object types (the field under the exercise relation) will always say “Running” or “Walking” or “Strength Training.” That’s how a collection database works. In the graph however the names of the pages are displayed, i.e. “Evening Run”, and so only one object labeled “Running” appears in the graph.
I understand, that’s one way to resolve this issue with the current features and functionalities of Anytype and for a while I was going to implemented a similar structure but I decided not to and wait for some iteration of multi dimensional relation to be added (hopefully). You see, I personally hate clutter and aim to create objects which all are different and meaningfull. That is just me but certainly your way of implementing it certainly works too
Anytype is working on Collections 2.0, so the database functionality will definitely improve in time. Perhaps closer to your ideal workflow that you describe.