# Queries where attributes are shared with function names?
**URL:** https://community.silverbullet.md/t/queries-where-attributes-are-shared-with-function-names/1177
**Category:** v1: Troubleshooting (legacy)
**Created:** [October 28, 2024, 2:55pm UTC](https://community.silverbullet.md/t/queries-where-attributes-are-shared-with-function-names/1177 "2024-10-28T14:55:22Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Pluckerpluck](https://community.silverbullet.md/u/Pluckerpluck)
#### Post date: [October 28, 2024, 2:55pm UTC](https://community.silverbullet.md/t/queries-where-attributes-are-shared-with-function-names/1177/1 "2024-10-28T14:55:22Z")
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:
```query
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:
```query
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!
---
### Author:  [@bent0n](https://community.silverbullet.md/u/bent0n)
#### Post date: [October 28, 2024, 6:36pm UTC](https://community.silverbullet.md/t/queries-where-attributes-are-shared-with-function-names/1177/2 "2024-10-28T18:36:02Z")
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:
````auto
```query
page where created > 2024-10-28 and created < 2024-11-03
```
````
---
### Author:  [@Pluckerpluck](https://community.silverbullet.md/u/Pluckerpluck)
#### Post date: [October 28, 2024, 8:24pm UTC](https://community.silverbullet.md/t/queries-where-attributes-are-shared-with-function-names/1177/3 "2024-10-28T20:24:24Z")
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
---
### Author:  [@bent0n](https://community.silverbullet.md/u/bent0n)
#### Post date: [October 29, 2024, 9:47am UTC](https://community.silverbullet.md/t/queries-where-attributes-are-shared-with-function-names/1177/4 "2024-10-29T09:47:05Z")
> [@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:
```auto
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.
````auto
```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?
````auto
```query
page where .getProjectTag = "test"
```
````
---
### Author:  [@Pluckerpluck](https://community.silverbullet.md/u/Pluckerpluck)
#### Post date: [October 29, 2024, 10:43am UTC](https://community.silverbullet.md/t/queries-where-attributes-are-shared-with-function-names/1177/5 "2024-10-29T10:43:35Z")
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.