Doc attributes changed themselves?

When a user signs up completely and they have their own unique document in the central user database, I have it stored into internal memory via Hive to later be compared with a new fetched document once realtime detects a change to it. I have a for loop to run through each value of the document to compare it to the original to see what changed. For whatever reason, the pendingFriendsList attribute always says it's length is different despite any changes. It seems that whenever I fetch the new/updated version from the DB (despite any changes), it has a default value of 1 (empty). But when the account gets the first instance of the document when finishing signing up, it's length is 0 (empty). When I add values to it, I do receive the correct amount. And when I delete them it goes back to 1. Why is it that whenever I receive the first instance of the Doc after signing up it's length is 0 and not 1?

Sorry I don't really understand

Yeah its hard to explain. My app's flow consists of signing up and adding a User to a central user db (refer to the attributes in the picture). Now, in order to incorporate a friends list I have two arrays. Both are empty when created and aren't a required attribute for on creation. In order for this to work the client will listen to any updates to their respective document via Realtime, and getDocument. This client will refer to this new fetched instance of their document and compare it to the previous one saved in internal storage user model(via hive). The problem is that comparing these instances of the DB document states that the pendingFriendslist and friendsList are not the same (Same value, different length). Even though I only made an update to userProperties (removed a value / refer to pic), it still flags the two array attributes as being changed despite not changing them. Conclussion: The first time I grab a doc for the user the length is 0 and even when not updating these arrays, the doc I revieve post update has a length of 1 despite nothing being changed to it.

What's your code?

I think some update you made actually inserted an empty string. That's why length is 1

The first relevant part of this is when the user first signs up and goes through the sign up flow, followed by creating a persisted user model (The first Picture). The two 0's being printed from the terminal are essentially the same since they are calling to the user document for the first time. Now, lets say later I update the user doc's attribute ( delete the gaming & beach property ) in order to trigger an update, triggering a comparison from the first picture's internal document to the new one.

After triggering an update I am comparing the internal model's data from before to a fresh document that is being returned by the following function ``` Future<Map> returnDocumentData(String id) async { var docCert = await _db.getDocument( databaseId: '637044216b476709d41d', collectionId: '63704487a16832bfd730', documentId: id); var result = await docCert.toMap()['data']; print(result['pendingFriendsList'].length);

return result;

}```. Essentially I am not inserting an empty string at any point.

How did you update?

@Snippy here's the thread. Let's keep the conversation in here

It would be good to copy your message over here and then close the other post

I have concluded that empty arrays are defaulted to a length of 1 (empty string) after updating document despite the array not being the updated value. Awhile ago I was having a problem in which was really tedious for me to figure out. Following an update to a user's respective document in the DB of the Appwrite instance I can conclude that empty array's that are yet to have values are defaulted to an array of length 1 where index 0 is an empty string. Initially (before an update to a document) the length is 0 and has no empty string. But for whatever reason all empty arrays default to a value of one after the doc has been updated. Note: I am not updating any array values in the doc. It's important to note that if I do make an update to the respective array in the doc (such as adding one string), the array will change to that of an array with one value (length 1). This was really inconvenient for me because when I would listen for ANY changes via realtime and compare them to the first instance (first instance = document that has never been updated; all arrays with length 0) I would compare an empty array to a fake empty array (length 0 vs length 1 with an empty string). My solution was to update the document before assigning the document result to an internal user model for future comparisons. This way the first instance ever fetched will have non-required arrays with the same weird empty string in the 0th index of the array.

Was it made to be different when updating from console vs client?

So you can take a look at the network request of the update in the console to verify the problem. My assumption is it's a bug in the console in dealing with empty arrays

What do you mean

in your browser, open the dev tools, switch to the network tab, try an update, look at the network log