Admin
If those are IDs, you could iterate over the new data and issue a get request for each one. Get document API calls are cached so they should be faster than list documents from a server side processing standpoint
Votes
0
Replies
24
Participants
Unknown
Messages
25
Admin
If those are IDs, you could iterate over the new data and issue a get request for each one. Get document API calls are cached so they should be faster than list documents from a server side processing standpoint
Rank 3: Container
i see. unfortunately those are not documentID, but a custom ID. Which means, i can only use listDocuments. I will take note of this. I may consider converting the custom ID into document ID. Thanks for your input @Steven
What if you enforced "unique" on an index and just failed the createDocument request?
I wonder if the performance would be better with less calls 🤣
Rank 3: Container
Thanks @VincentGe .the thing is, I'm not trying to insert doc, but merely doing a verification whether any of my existing papers have been removed.
🤔 interesting. Large volume data handling is really something we haven't done a ton with. I wonder if we can batch this operation with graphql
@Steven From what I remember, one of the cool things about our new graphql api is that we can batch many calls at once 👀
Admin
Ya but in this case, there's a bit too much data to batch in one graphql request
🤔
Rank 2: Process
Eu… just a random thought, @Said H why don’t you combine your Appwrite instance with something like meilisearch? It’s optimal for searching and is very powerful at that…. It could help lessen the burden on Appwrite?
Rank 3: Container
hey @Olivier Pavie , thank you for the suggestion. I will take a look at meilisearch 🙂
Rank 3: Container
I just learned the tutorial of Meilisearch @Olivier Pavie, and i noticed that we are feeding our json data to the system. That gives me an idea that we too can do that in appwrite, yeah?
Admin
It depends on what you want to do. I would assume Meilisearch's full text search is a little smarter than mariadb's
Rank 3: Container
it has smarter search, but i wont need that. i just need to be able to read the record
Rank 3: Container
i am inclined to create a string array attribute to handle these large data. but i worry there is a size limit to that
Rank 3: Container
i can do a 1x call to the doc, then process the comparison in the code. it'
Rank 3: Container
it's a fast comparison, since each record will have its unique ID
Rank 3: Container
so, i will end up having 1 doc containing 5k array records
Rank 3: Container
but i only need to do 1x call to this 1 doc
Rank 3: Container
i can give it a try, if you are unsure whether there is a limit to the max array record length 🙂
Admin
It might be best to use a very large string attribute and store a JSON string where the JSON string is essentially a lookup table {"id1": 1, "id2": 1}
Rank 3: Container
i see. this is fine too
Rank 3: Container
i can use this. and the comparison will work in my case as well
Rank 3: Container
alright. thanks everyone 🙂
Admin
[SOLVED] Compare large data