Lesson 5: How to Power Your Workflows Using Properties and Dynamic Variables

Because there is no block with this property:

example:: first, second

If you want to list blocks with “first” only and blocks with “second” only, you need to use OR, not AND. See the lesson on boolean operators.


[Edit] somehow I think the syntax we use in Boolean Algebra is less ambiguous in this case:

[[Apple]]+[[Banana]]

is the OR operator and that + gives the idea that the list increases.

1 Like

In lesson 5 I read " any property you add to a block is applied to the block itself and all of its children .". I will think even harder about this and try to work out examples. At the moment, unfortunately, I don’t understand any of it. In any case, thank you for your response.

You’re right @DjeeAr, this query should work given the fact that both values are part of the same branch. Just to make sure, are you on the latest desktop version (0.8.2.)?

(:point_up_2: this is not correct; see replies for the reason why block properties aren’t applied to a branch)

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:

  1. It slows down search and queries.
  2. 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 :wink:

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.

2 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.

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.

1 Like