How could they inherit properties? Properties are used to define thinghs like being collapsed by Logseq itself and its plugin.
I’m pretty sure that making blocks inheriting properties now would result in breaking a lot of stuff…
1 Like
Yes, I make sure to always be on the latest revision.
I would hate to see time spent on this inappropriately afterwards. Let it rest for a while. They are sought after examples. They have no immediate practical value.
@Ramses FYI my proposed syntax for inline properties could be also used to make child blocks inherit properties:
- [[type:: book]] [[author:: Oscar Wilde]]
- [[title:: The Picture of Dorian Gray]]
- [[title:: The Importance of Being Earnest]]
A query listing books would result in this:
| Title | Author |
|---|---|
| The Picture of Dorian Gray | Oscar Wilde |
| The Importance of Being Earnest | Oscar Wilde |
1 Like
@DjeeAr, I checked with @tienson, and @alex0 is right: block properties are not applied to their entire branch, only to the block itself. According to Tienson, the two main reasons are:
- It slows down search and queries.
- It makes refactoring later harder. Currently, properties are not blocks, they are just scalar values like texts or numbers, which means they’re not yet first-class “blocks”; properties need better schema and grouping support to bring ontology to Logseq.
And @alex0, as for:
I’m not sure how that would work performance-wise, given Tienson’s explanation above. But I’m out of my depth when it comes to engineering 
3 Likes
Ramses,
Also, in his Logseq Mastery course, Dario tells me in lesson 10.4
“Make sure to indent so that all links are inheritable.” So this is a somewhat more widespread misunderstanding.
The keyword is links. Links are inherited; block properties are not inherited.
If you want to apply a property value to an entire branch, make a [[link]] of the property value. In that case, the link is applied to the entire branch. However, the block property itself (key-value pair) only applies to the block it’s part of.
3 Likes
I did an experiment. Block properties are not inherited while page properties are.
{{query (and (page-property SomePageProperty spp1) (property SomeBlockProperty sbp1)) }} only returns blocks on pages with spp1 and where the block has sbp1. Even if sbp1 is a link, child blocks are not returned.
To get block-level inheritance with linked properties this works:
{{query (and (page-property SomePageProperty spp1) [[sbp1]] ) }}
So I guess that if you want block inheritance it’s ok to use #xyz or #[[xyz]] in the parent block if you don’t want a property.
Incorrect understanding by Mage:
I’m also using “:property-pages/enabled? false” so that unless I specifically create a linked property like [[linked-property]] logseq doesn’t automatically create a page, and I can see no changes in the data returned by queries.
(Alex pointed out the pages are created for property names, not values.)
Am I missing something important about properties vs linked properties?
Thanks, Mage.
Correct. See my previous comment in this thread:
2 Likes
So basically (page-property ... ...) equals to “list blocks that are on pages with this page property”.
But what is this supposed to return?
Logseq creates pages from properties names, not values. Maybe you are confusing the two? Otherwise maybe I didn’t get what you mean.
1 Like
Hi Alex,
This returns blocks with link [[sbp1]] and their children on pages with page-property SomePageProperty:: spp1.
The block link can be either a property with a linked value or just a link/tag.
Thanks for the clarification about “:property-pages/enabled? false”. I was confusing property names with values. Now I will have to consider the consequences of not automatically having a page for each property name.
1 Like
I think very few people who read this
will understand it like this:
Might need clarification there.
2 Likes
{{query ... (page-property ... ) ...
will return pages with specified page property
{{query ... (property ... ) ...
will return blocks with specified property
{{query [[link]]}}
return blocks with [[link]] and children of those blocks. (and of course the page with name Link and all blocks in that page). This is the only valid inheritance rule.
These queries
{{query (operator (page-property ...) (property ...) }}
{{query (operator (page-property ...) [[link]]}}
should return error, it’s basically type error, trying to group pages and blocks together
And it does return error for me.
1 Like
Thank you for pointing this out, as the lesson is indeed incorrect. Sorry for the confusion, but I also had a wrong understanding of how block properties work.
I’ve now updated the property section.
Thanks. Getting clearer every day.
I can not confirm the error you mention when combining properties and page-properties.
I’m on Logseq 0.8.4
block properties are not applied to their entire branch
It is also like this in org-mode and, there too, for performance reasons. Tags (links in Logseq) are inherited while properties aren’t.
@Ramses it confuses me that you say that sort-by is just for pages because only pages have creation and modification dates. But AFAICU sort-by may be used in order to sort by other properties, so why would it just work on pages?
I’ve learned that later as well, but I wasn’t aware of that at the time of writing these lessons.
However, the way sort-by is used in the course is by sorting on dates. The thing is, only pages have the date properties (blocks don’t at the moment, due to performance issues). That’s why I said they only work in combination with pages. When I run another cohort of this course, I’ll probably show how to use sort-by in combination with other properties.
2 Likes
how do you make that timestamp?
Type / to open the command palette and start to write “timestamp” for autocompletition
3 Likes
Thank you,
what a great feature.
2 Likes