Sorry if its a stupid question:
I have to update 2 “fields” under a “master key” in Firebase, but when I save it using the “create object with fields” all the other data under the same key is deleted. Because is a long list of fields, do I need to put all the fields in order to preserve all the data, or there is another way to do it without write all the fields again?
My code and comments below:
Any another way to save it without loose data, just updating the fields I need?
When I’m doing something like you try to do, first step for me is to retrieve data from Firebase using a variable and get block… this way an object with the same structure as my firebase is created.
Next step, ill change only the data i need to be changed in that variable…
In your case, something like
Same for your second “INICIO” field.
This way, only these fields are updated, keeping all others just the same as was retrieved.
After that, save entire variable to firebase, using “save” block, as you do.
Not a stupid question at all!
I prefer to use cloud variable names for this instead of the Realtime DB blocks. In fact, this is recommended by Thunkable in the documentation.
You would do set cloud variable [join] where [join] is the join block you have above but you would need to join “STATUS” as well or “INICIO”. And then for the value, you would use either “ATIVO” or the app variable data_inicio blocks.
Yeah… I understand this approach… but the point here is that unfortunately you will need to “read before write”, consuming time and network…
For apps that are critical and with massive use, this will cost a traffic overhead…
That’s why a looking for a direct approach, or the other way is to change de structure of the database to avoid this situation, putting this “constant changing data” in a separate key… it’s not elegant, but maybe can help…
But I think this can be something to consider in the futures implementations of thunkable, don’t you agree?
Accessing stored variables can be slow so I recommend setting the app variable UserID to stored variable UserID and then using app variable UserID when accessing Firebase.
I found no lag in using this method by reading-writing to Realtime Firebase, that is running extremely fast at least for me…
And my app is handling a lot of data aswell:
I swear I’m trying to learn how to use cloud variables for other purposes than only store ID sequences 
But in the case I have a “customer” master key (/CLIENTES), under this customer key I have other sub-keys like “contracts” (/CONTRATOS), and each new contract receive your own ID (feeded by a cloud variable called ID_CONTRATO, that I use as a numeric sequence). And each contract ID has lots of information inside, and for times to times I need to update the “STATUS” and “INICIO” fields (status & start date in portuguese).
And cloud variables are stored in the 1st level in the database, so the database structure stays very confusing to manage when you have this kind of hierarchy trying using cloud variables…
But because I’m new (3 weeks only) in thunkable maybe I need to learn how to accommodate this type of structure using cloud variables…
Anyway, I know how to solve, it’s the longest way, to save ALL fields (after reading them), just to update 2 fields, or change the structure of my database…
But it’s costly in labor terms and I/O in Firebase…
Reading a lot about Realtime Firebase, I understood that data are kept there as JSON. And that means that even if we (and by “we” I talk about me and others used with row/columns/fields data type organization) see it as a structure that looks like fields, in fact under a key there is an organized object.
That’s the reason that my approach works like a charm, instantly and very easy to handle - it’s natural for Firebase to handle objects, as it is it’s own nature 
This is my beginner explanation and make me not worry about time consuming when using this method 
@tatiang I don’t see how to create dinamically this kind of variable in Thunkable X…
I see that this type of block is allowed only in the new version… correct?
So, I will need to move all my project to the new version to use this type of declaration of cloud variables or there is a way to do it in X ?
Thunkable X is the current and only version of Thunkable available right now. I think what you are asking is if this can be done in the older “Snap to Place” (StP) interface instead of the newer “Drag and Drop” (DnD) interface.
In both interfaces, you can find it near the bottom of the variables drawer. The set app variable "name" to [ ] block can be configured so that it says “cloud” instead of “app”. And then you enter the path to the Firebase node in the “name” section, as I showed above.
You are right! It’s just because I was looking for the “initialize” block to declare the variable with the “join” structure… but if the SET block works, so let’s do it
Thanks!
