Replies: 25 comments 39 replies
-
For nulls I prefer |
Beta Was this translation helpful? Give feedback.
-
What about not equal? 😈 |
Beta Was this translation helpful? Give feedback.
-
One to many and many to many is it already possible? |
Beta Was this translation helpful? Give feedback.
-
How about alias for equal too? |
Beta Was this translation helpful? Give feedback.
-
Would like to have some kind of join filters between collections. Also some aggregations would be nice to have. |
Beta Was this translation helpful? Give feedback.
-
+1 for being able to query where an attribute is null/not null. |
Beta Was this translation helpful? Give feedback.
-
By correcting the "Inconsistency Between SDKs and HTTP ", would AND/OR still be the same? For example,
be the equivalent of |
Beta Was this translation helpful? Give feedback.
-
Would Also, would case matter when creating a query? i.e. would "Smith" and "smith" be considered different? |
Beta Was this translation helpful? Give feedback.
-
Is it possible to drop the requirement to have an index set up for every possible combination of attributes that you might ever want to query? I don't understand why that's necessary, and it's a major annoyance and must surely be slowing down document create/update operations, for little gain if a particular combo is only rarely used. It should surely be sufficient to have indexes on each individual attribute, except in the case that you want to enforce a unique key across a combo. |
Beta Was this translation helpful? Give feedback.
-
Feedback On Proposals: class Query {
...
lessThan(attribute: string, value: Value | Value[]): string;
lessThanEqual(attribute: string, value: Value | Value[]): string;
greaterThan(attribute: string, value: Value | Value[]): string;
greaterEqualThan(attribute: string, value: Value | Value[]): string;
...
} Want/Need i.e. database.listDocuments("books", [
Query.leftJoin("author", [])
]); should return (1) {
"bookId": "string",
"name": "string",
"author": {
"name": "string"
}
} not (2) {
"bookId": "string",
"name": "string",
"author.name": "string"
} I'm assuming option (1) is going to happen anyway, but it might seem a bit conflicting. From the SQL perspective, a join denormalises the data into the same "table". |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Bit of a random idea, and it is solvable, but could maybe be a nice to have built in; a reverse limit; Say you order the data by $created asc, and you want the last 50 records added, in asc order. Just a thought, not something I need right now, but I can imagine it could be a useful shorthand for messaging apps, getting updates and so on. |
Beta Was this translation helpful? Give feedback.
-
Can we support a unified negation interface
|
Beta Was this translation helpful? Give feedback.
-
@appwrite Team Missing from the Query class description above (copied below)
is the |
Beta Was this translation helpful? Give feedback.
-
I think OR query is not fully supported . For example if I want to make this query: SELECT * FROM Products WHERE Title = 'abc' OR Price < 100 I can't do this by only one request. |
Beta Was this translation helpful? Give feedback.
-
@Meldiron Is there an estimated time for the new version? It would be great if I could at least have some idea. Only if I can get a time estimate for the new version will I plan accordingly in my projects. Thanks for the good planning |
Beta Was this translation helpful? Give feedback.
-
Will we support GROUP BY/SUM/COUNT operations too? If not, what is the proper way to aggregate data in AppWrite? |
Beta Was this translation helpful? Give feedback.
-
For example, how do I list the distance between 2 locations (user location and product location)? |
Beta Was this translation helpful? Give feedback.
-
I wished listing could retrieve more than 100 items, some times it's necessary. Any thoughts on this? |
Beta Was this translation helpful? Give feedback.
-
There is no description how to use queries in REST API ! |
Beta Was this translation helpful? Give feedback.
-
I have a strange error, when I run Query.orderDesc("attribute") I get the following error code: Invalid query: {"method":"orderDesc","attribute":"$createdAt"} |
Beta Was this translation helpful? Give feedback.
-
Is there no query to get a specific amount of random documents from a collection? |
Beta Was this translation helpful? Give feedback.
-
I think Appwrite could look at what Directus did for query |
Beta Was this translation helpful? Give feedback.
-
There is no description how to use queries in REST API as I checked today! |
Beta Was this translation helpful? Give feedback.
-
👋
helloWorld()
We noticed some limitations in our current querying system and we wanted to hear your opinions on this topic 😇 We plan to introduce these changes in Appwrite 0.16, which is just around the corner! To learn more about the current implementation, visit our docs: https://appwrite.io/docs/databases#querying-documents
🤖 Too Many Arguments
We plan to remove arguments:
All of these capabilities will remain in the endpoint but will be achieved by a query inside the
queries
array attribute. We decided to do this in order to lower the number of arguments (making docs a bit simpler), and also improve code quality in languages that don't support named parameters.This is what your current JavaScript call might look like:
With a change to parameters, we will move from 9 parameters to only 3 and our query could look like this:
🧹 Inconsistency Between Endpoints
listDocuments()
on databases is the only powerful endpoint with many querying capabilities.listUsers()
, for example, doesn’t accept queries, accepts search, and sorting functionality is limited. Team memberships have "get" instead of "list", and function executions can't even be sorted. A bit messy 😬We plan to remove all of these attributes and make sure to introduce one new attribute
queries
to all of the internal endpoints too. This will allow us to keep everything consistent and give you much more possibilities with querying internal tables (users, teams, functions...).Regarding internal collections, we will come up with a list of the most useful queries, and prepare indexes for them - to make them fast. We will also allow unindexed list operations to make sure we are not limiting users in any way. At least not at this stage.
🧹 Inconsistency Between SDKs and HTTP
As of right now, you build a query in SDK using
Query.equal("nick", ["Meldiron", "Eldad"])
, but over HTTP query is sent asnick.equal("Meldiron, "Eldad")
. This means you not only need to learn SDK syntax, but you also need to learn HTTP syntax if you ever want to use that. Terrible! 😔We plan to keep the same syntax on both SDK and HTTP. You noticed how SDK can either do 1 option (
equal("nick", "Meldiron")
) or multiple as array (equal("nick", ["Meldiron", "Eldad"])
)? We plan to build the same syntax support into HTTP too - so you can use both syntaxes with HTTP communication.Here are some examples of what it will look like:
🤨 What Is
lesser
?!?We looked at some terms we used and decided to rename them to proper English:
Shiny new query methods
Do you remember we removed some arguments from the list endpoint? This is how you achieve the same logic with new queries:
Some important terms:
What we did:
limit(10)
and thenlimit(15)
)orderAsc/orderDesc
), they will all be used in order of how you provided themlesser
,greater
...) , they will all be used withAND
in betweenA possibility is to also start introducing aliases when they become necessary. A good example could be a pagination query:
Another candidate for aliases are filter queries, since they can get pretty long:
📚 Update All Resources
Documentation needs to be updated to reflect this. First of all, the "queries" section in "databases" should now only talk about how queries affect indexes and via-verse.
Next, we should have the "queries" section where we explain the syntax and all possibilities. Of course, with code examples. If we decide to implement some aliases, all of them must be documented and what they are aliases of.
We should also look at "ordering" docs, and explain how to do compound sorting since the new syntax is different.
Following is a list of all query methods and expected parameters:
🔮 Future of Queries
As seen from recent updates, we are trying to improve each and every service of Appwrite. We take all of your suggestions into consideration and actively talk about them. Although we can't promise a release date yet, we find it important to always think about your suggestions.
In the future, we plan to see how join could be introduced into Appwrite. Here is a sneak peek of what a join query might look like using new Appwrite query methods:
We also actively think about geo queries being built into Appwrite. Such a geo query could look like a simple filter query method:
Then, we looked at responses and decided a new type of query method might be useful in the future:
You could not only specify what attributes you are interested in, but also could do operations above groups of data:
Last but not least, we thought about a small improvement to NULL queries, and were thinking about adding a new filter query method:
Now it's your time to shine! ✨
Do you have any feedback regarding these topics? Do you find new query syntax cool or complex? Do you agree with all of our ideas, or dislike some? Can you see some use cases that are not covered by this implementation?
Whatever is on your mind, let's chat about it.
EDIT 1.0
Query.equal("name", null)
seems to be more developer-friendly thanQuery.equalNull("name")
eq()
asequal()
shorthandBeta Was this translation helpful? Give feedback.
All reactions