Ref link on table seems broken on 2.6.1 ?!

v2: Troubleshooting
1

Hello there. I'm a bit late to the party and just catched up 2.6.1 this morning.
Doing the daily review now and just noticed that the ref property used in a query doesn't seem to work as before anymore.

I have a very simple query:

${query[[
  from p = index.tag "page" where p.name:startsWith("Inbox/")
  order by p.lastModified
  select {name=p.name, ref=p.ref, lastModified = p.lastModified}
  ]]}

Noticed that the ref column is not clickable anymore. Its basically showing the same as the name.

As a workaround i'm doing the concatenation with "[[".. p.ref .."]]", but it doesn't feel very elegant.

Did anything change in the recent releases? or am i just tired and the ref property was never rendered as a link :slight_smile:

2

Right, we tweaked a lot around rendering of queries. This may have been broken along the way. I’ll investigate.

3

Fixed this on main now, will be in edge builds and will be part of next release.

4

@zef I strongly oppose this "fix", really. It's semantically wrong to "fix" this. The SLIQ result rendering widget SHOULD NOT interpret data. What if I don't want the ref rendered as a link? What if the ref comes from custom p = { { ref = false }, { ref = true }, } and has therefor completely different meaning (and boolean, btw, is not covered in the fix either)?

The OP's '[['.. p.ref .. ']]' is one of the correct ways to make the ref be a link, if needed. If there was such support before, that was bug. It was fixed some day and now it's reintroduced.

Try to project select '<'..p.ref..'>' and you will end up with complete non-sense! In my case: [[<Inbox/Wednesday/2025/August/13>]], for example.

The widget should only show values of the raw columns! Raw column MUST NOT be rendered anyhow differently than as some standard rendering of string, number, boolean, table and NULL (and maybe some other things). In fact, it should be only inside the table cell, raw content, with HTML attributes as hints and some sound default CSS for them.

Special kinds of projection of a column values is user's duty. From my point of view, the fix (re)introduces real bug. Please, revert.

We can further discuss this, we can glue this in the SLIQ, if really needed. It would be much cleaner if we allowed custom types in SLIQ and make the ref be of type ref if it comes from index.tag collection and anything else if it comes from elsewhere. That way we can have both, custom refs and typed refs that then CAN be then rendered as [[ ... ]] without collision. Each custom type could have it's own presentation methods. But what about: '[['.. (p.ref or 'oops') .. ']]'? So we will also need conversion layer between the decorated ref type and native Lua types. So each custom type could have it's own conversion methods.

Well, I think to revert the fix and let users decide what to do with the ref would be much easier now. But still, it's worth considering. Postgres for example also allows custom types, why not SLIQ? (I've been playing with the idea for some time, TBH.) :slight_smile:

5

Yes, fair pushback. I introduced it back in the day as a convenience that would work for 90% of cases, but it is kind of a flawed idea. I'll revert it.

6

The idea is not "flawed" and I understand it. You could also oppose that one can select tostring(p.ref) and voilá! But it should be the other way round, therefor I oppose. The idea is not "flawed" if we implement custom types for SLIQ. Then this functionality will be back because we establish that ref type has this projection: '[[' .. ref .. ']]' and it will work out of the box. (Noted down.)

7

I didn't look too deep in how the query engine works but @mjf seems very confident :slight_smile: .

Although the naming , (being the second hardest thing in software development), is confusing. If its called ref I would expect it to be a reference,pointer,link- something that takes me to that page. With what @mjf is saying as I understand correctly , now the column ref is the same as the column name.
I recall probably somewhere on the video tutorial series of @zef that he used ref and name to show the distinction and thats how I ended up using it.

Nevertheless I wouldn't put too much energy on this. Having "[[".. p.ref .."]]" is good enough. Actually I'll change everywhere to use p.name instead.

8

ref is SilverBullet terminology of id basically, it's supposed to be a (ideally) space-globally unique identifier of an object. For pages that's conveniently simply the name, but for other objects (like items) it defaults to the page name with a position (e.g. somepage@321) within the document. The nice property (that mostly holdes) if that you can always use it as a link, that's why the [[ wrapping works.