Queries where attributes are shared with function names?

[Pluckerpluck (Sammy Gillespie)]

I’m not sure if I’m going crazy here or not, but I enhanced my journal pages so my daily pages would have a frontmatter tag:

weekStart: {weekStart}

I want this to show in the weekly journal, so I have:

page where `weekStart` = "2024-10-28"

And this matches with EVERY page, because I assume weekStart is being processed as a function and I’m ending up with:

page where  "2024-10-28" = "2024-10-28"

Is there a way to stop that interpretation and force it to use the attribute name? It’s pretty risky to have functions always take precedence.

Like if I add a function in the future (or you do) my entire system could collapse!

[bent0n]

Not sure on the issue you are having.

However, my advice would be to not have a weekStart attribute. It seems easier to adapt the query and use existing created attributes:

```query
page where created > 2024-10-28 and created < 2024-11-03
```

[Pluckerpluck (Sammy Gillespie)]

Oh yeah, I’m happy to do that, but:

1. It requires a custom function to add a week to the first date (as in practice it’s not static, but dynamic), I was trying to avoid that
2. It doesn’t change my worry that I may be using a name like weekEnd and one day a new function is added into the software, resulting in all my attribute queries failing suddenly

[bent0n]

@Pluckerpluck

It requires a custom function to add a week to the first date (as in practice it’s not static, but dynamic), I was trying to avoid that

I understand. It’s just I’m not a fan of having an attributes that is directly derived from another one.

Maybe you could use the function in the query instead of creating an attribute:

page where weekStart(created) = "2024-10-28"

This would work around the issue in that case.

@Pluckerpluck

It doesn’t change my worry that I may be using a name like weekEnd and one day a new function is added into the software, resulting in all my attribute queries failing suddenly

After your first post I didn’t fully realize the issue you were mentioning. It does seem like there should be a way to force the use of attribute instead of function.

Using live template you can access the attributes but it’s an ugly workaround, not a solution.

```template
{{#each @page in {page}}}
{{#if @page.getProjectTag = "test"}}
success
{{/if}}
{{/each}}
```
```query
page where getProjectTag = "test"
```

The above renders to:

The error is part of my getProjectTag function which shows the function is indeed running instead of checking the attribute.

I would argue that it’s bad practice to have an attribute and function share a name. However, many function are not under the user’s control (from SB core or plugs) and could indeed conflict with existing attributes in the future.

Maybe something like a . as a prefix to force the use of attributes in case of conflict could work?

```query
page where .getProjectTag = "test"
```

[Pluckerpluck (Sammy Gillespie)]

I agree that a dot would be perfect assuming no other conflicts. And it is exactly because functions are outside of the user control I was worried about this when I noticed it. I can easily avoid this problem right now, but I don’t want my notes to fail in the future.

And for what it’s worth, I was avoiding created simply because this way I could more readily switch which week a note belonged to manually, or avoiding a situation where I may end up restoring a file manually etc and screwing with the files metadata. But I have moved to a dynamic calculation using the note name instead. Still required a custom function though, as week start doesn’t accept an argument, it’s always today’s date.