Query.select(["status", "api_id", "owner", "$id"]),
returns databaseId, collectionId,
{
status: "active",
api_id: "12345",
owner: "65cc7a4c9b65506c17cf",
$id: "65cc823e3398ce82bf03",
$databaseId: "dashboard",
$collectionId: "jobs"
}```
is there a way to hide the not neded data, databaseId and collectionId that we already know, because we are requesting in it ?
Looks like it's not possible to query select on those attributes 😬
i don't want to query on them ,i want to get rid of them from the response
Yes, that's what I mean
imagine you request 1 element, you get 3 instead, its too much data
Yes, I completely understand. It's like a bug. Not sure if it was reported previously on github, but if not, It would be great to make one
Previously something similar happened with id and creation/edit dates and got solved if I'm not wrong
since we are on the topic of collections, one guy was asking today about due date, i was wondering if qe can querry with larger than dates as well?
could not find any examples
i will try to report that on github then, hope its not bilion questions to file in
@D5 you know to which repo i should be reporting that? appwrite/console ?
or is that sdk github?
Appwrite/appwrite will be best for this issue, I think
Check if it got reported previously, maybe someone else already created an issue
wdym?
something like Query.greaterThan("score", 10) for datetime
here's an example of the guy using due date -> https://discord.com/channels/564160730845151244/1207253709231366144
i wrote an example for him, but it should be done with querying past date not like currently made, as its unefficent
Recommended threads
- Seed db
hello there... is this correct way to seed appwrite
- Query Appwrite
Hello, I have a question regarding Queries in Appwrite. If I have a string "YYYY-MM", how can I query the $createdAt column to match this filter?
- Type Mismatch in AppwriteException
There is a discrepancy in the TypeScript type definitions for AppwriteException. The response property is defined as a string in the type definitions, but in pr...