I fully support this.

As an addition, it would also be great to have symbolic links; then one could integrate much more with the filesystem.

This is great 👍 @frostime , I was thinking of posting the Google Translate version I had been using myself.

Hi, @revachol, your question and @WanChen's answer helpe me come up with a solution to a slightly related problem: Advice on how to improve a database template

Thank you!

I asked about it in this thread. So far I've managed to use the document id only when using the query plugin, but then I can't render the blocks like the default embed block sql queries do. I don't know how to use the id from within a normal sql query.

Presumably, Javascript could help here, but I could not find any documentation about //!js blocks, and I can't get a minimal working example just from the GH issue (translation by Google).

This can actually get very bad in other contexts, see below the bug in action in the search widget.

@88250, @Vanessa is better to report as a bug in GitHub?

Hi, I suffer from the same problem: garbled tab labels

I am on Linux - PopOS! 22.04, using SiYuan 2.11.3, my laptop has an integrated GPU.

Hi,

Tagging @zuoqiu as well (author of widget-query?).

Reading the documentation of the widget and exploring the Refs table (use the source 😉 ), I have come up with the following SQL query

SELECT src.* FROM blocks AS src WHERE src.id in
	(SELECT refs.block_id from refs 
		WHERE refs.def_block_id='.block{.root_id}');

This actually does what I want, i.e. it lists all the blocks pointing to the query's root block (in this case, the doc that contains the query). But

1. widget-query renders the output as a table. I would like to render the blocks normally. Is there a way to do it like in embed block queries?
2. alternatively, I could in principle use the same query in an embed block. But when I do, this produces no results. My question here: is the dot syntax .block{.root_id} that accesses properties of the current block not allowed in normal embeds @88250 ?

I have searched extensively but so far I haven't found a comprehensive documentation of the query system, though I am thankful to @leolee9086 for sharing some examples in the forum.

Please let me know if you find ways to improve my query above!

Thank you everybody for your patience, and apologies that I just discovered the forum has a threaded reply function.

Á.

edit:

1. changed = to IN in query so as to be able to list multiple incoming links.
2. simplified the nested query, blocks as def not needed for it

Hi again,

I am wondering if using Javascript in the embed block could help here. Because I only get a partial translation and I don't know JS, I don't follow much of what is discussed in the feature request with issue number 9648, proposed by @frostime

@frostime -- wout be possible to dynamically acquire metadata from the environment (current notebook/doc, preceding block, enclosing superblock) for use in a query by using the new //!js embed functionality?

Dear @ciwoyipang, thank you so much for making me aware of the query widget. It is a very featureful extension. But I think I did not describe my need clearly. What I am after is that the query block asks its parent for the text "trip to the moon", i.e. that string in the query should be generated automatically from the context.

select * from blocks as b where b.content like "%insert here the title or the name of the parent block%"

So if I put this query inside a document named "The mother of all queries" it would automatically fill in the value and execute

select * from blocks as b where b.content like "%The mother of all queries%"

Do you have an idea on how to customize queries based on the context of the query block (e.g. the parent, or the preceding block)?

PS. in order to have the type column values translated, is it necessary to do it in Siyuan or in the widget code?