Best way to have a page of queryable records

What I’m trying to do

I’m looking to migrate to Obsidian from Logseq and am having trouble replicating Logseq’s ability to store properties on blocks (in Logseq, one block = one line of markdown, basically). I use this to have a single long page containing a giant list of records, which looks something like this:

- entry:: 235
  kind:: B
  person:: Bob
  country:: USA
- entry:: 234
  kind:: A
  description:: my description here
  time:: 8:02
  person:: John

The idea is that different records are mostly the same but can have some different fields, so a single table wouldn’t necessarily be appropriate. In Logseq, this format gives me a bunch of records I can query using its querying system.

In Obsidian, it doesn’t seem like it’s possible to query or attach data at a level more granular than entire pages. So what would be the best way to achieve this collection of records?

Things I have tried

Although it should work in theory, I do not really want to have a giant folder of records with one page per record — that seems like overkill and would be very annoying to manage.

One possible solution would using dataviewjs and then JavaScript Class Inheritance or some other coding approach.

Sure, but where would I store the data to start with?

The idea of Dataview and Dataviewjs is to process your notes. You can process them all to RAM and then run your code to extract stuff. Obviously that requires knowledge of programming.

Ok but before I can make a Dataview query I need data to query/view. Where would I put the data.

Man I wish I could delete someone else’s comments right now. I know how to program. My question is not how to process data I already have, it is WHERE AND HOW DO I STORE THE DATA I WANT TO PROCESS. YOU DO NOT NEED TO KNOW HOW TO PROGRAM TO ANSWER THIS QUESTION. IT IS A QUESTION ABOUT OBSIDIAN.

Sorry I assumed wrong, I will delete it

Try the following in a file:

- [entry:: 235]
  [kind:: B]
  [person:: Bob]
  [country:: USA]
- entry:: 234  
  kind:: A  
  description:: my description here  
  time:: 8:02  
  person:: John  
- (entry:: 236)
  - kind:: C
  - description:: my subitems here  
  - time:: 8:08
  - person:: Johnny

`$= dv.span(dv.current().file.lists)  `


TABLE item.entry, item.kind, kind, item.children.time, nonnull(item.children.time), item
FLATTEN file.lists as item
WHERE file = this.file
WHERE item.entry

If you go to reading view you’ll see what dataview sees when using the various notations.

Your original format (the second one in my example) collapses all the text into one entry item, and there I don’t think you can access the bits and pieces of it.

In the last example I use subitems to create different contexts separating the various fields, but it’s not really easy to access them here either.

So my preferred method would be the first variant where you enclose each field in either square brackets (where the key value is shown), or normal parentheses (where the key value is hidden). The various fields are then easily accessible through simple dot notation after you split the lists in a file using FLATTEN.

1 Like

Thanks! I think there is one issue though, if you use $= dv.span(dv.current().file.lists) you get infinite recursion?

It shouldn’t be infinite, but it acted kind of strange every now and then… :slight_smile:

Thanks for advice guys

Note that you will get much better performance if you put where file = this.file first. Putting it right after table lets Dataview filter by file first (quick, easy), then flatten the lists in the current page. If you put the where file = this.file after the flatten, then Dataview must flatten every list in your workspace before filtering on file, which is expensive (and slow!).

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.