An awesome update to queries

Logseq’s latest query upgrade turns query results into real tables, making it far easier to scan, filter, and click through structured data stored in daily journals. The practical payoff is immediate: instead of getting a long list of records (or confusing blank rows when the queried property doesn’t exist), users can query a specific property type—like a “tweet” or “article”—and instantly view the results in a tabular layout where linked fields and tags are readable at a glance.

The transcript walks through the difference between a generic query and a property-driven one. When a query returns items that don’t share the relevant Logseq-defined properties, the table view fills with blank rows, which can look broken until the underlying schema is understood. Switching to a property-based query fixes that: querying for a property type such as “tweet” produces a table that includes the linked content and associated metadata. From there, the workflow becomes more useful than scrolling—shift-clicking a row opens the underlying page, and linked URLs can be accessed directly. This same pattern applies to journal content: entries created with a consistent “crumbs” metadata template (type, link, tags, and producer) become a searchable, table-friendly repository.

Books are used as a second example, revealing both the strength and a current limitation of the table output. Querying for “books” returns a clean set of results, but the table may not display the book title in the first column; instead, the first column can show the linked page/block, forcing users to open items to see details. A workaround appears tied to how metadata blocks are ordered: if the properties/metadata crumbs block isn’t positioned first within the book page, some books may not appear consistently in the table results. After adjusting the block order (and refreshing), missing entries return—suggesting the table feature depends on predictable placement of property blocks.

Beyond tables, the transcript highlights two additional query behaviors. First, text search supports quoted phrases (inverted commas) inside the desktop app, enabling precise matching—for example, searching for the word “objective” across the database. Second, indentation matters for hierarchical queries: if related links aren’t indented correctly, a query that expects a parent-child structure may return only the page that matches the correct sibling/child level. Re-indenting the content so the hierarchy aligns with the query’s expectations makes the missing page appear.

Overall, the update shifts queries from “find something” toward “manage and review structured information.” The table output rewards consistent metadata practices, and the indentation and quoted-text rules add precision—while the books example shows that a bit of schema discipline (and sometimes block ordering) is still required for fully seamless results.