APP ID: E9DF3457-FBDF-4D42-A6F3-FDFF2C260FF6
Hi, just setting up push notifications on Android following migration from backendless 3 to backendless 5
Followed all docs through on the setup guide
This line reports to work in my code
Backendless.Messaging.registerDevice(channels, new AsyncCallback()
Then docs say I can
verify device registration in your Backendless backend. To do open Backendless console and navigate to the Data screen. The device will appear in the the DeviceRegistration table:
However that DeviceRegistration table is not there to be seen. I just have Cache, Counters, Loggers and Users table under System Data?
Can you please share with us your migration archive with data? I’d like to try reproduce the problem, because manual restoring of the table in your DB would be not that easy
We migrated the data over a month ago, and I have only just spotted this table isn’t showing. I can restore that data later if necessary, but for now can you just give me a blank DeviceRegistrations table?
If that was that easy we would have already restored it. It’s not just an ordinary table, it’s quite easy to brake smth on manual intervention. Can you please share at least your 3.x appId which you migrated data from? I’ll try to assist with the problem as fast as possible
Sure of course it is 9FD83C1D-00B1-E549-FFAA-FC77B4421800
Sorry I didn’t realise I thought it would be easier to create a new blank table.
Tomorrow is very important day for our app, so can you please keep things running smooth tomorrow
Your application and the server itself will remain untouched until the end of the week, no worries
OK if you could look at this for me now please. Have you got all the info you need?
We have not taken any action since you asked for no activity because of the important day.
We will now deal with your question.
Thanks that’s great and thank you for waiting.
During the migration, you used the archive for 1/25/2019, 4:30:47 PM or 1/28/2019, 6:36:48 PM?
I migrated to two new applications using your two archives. In both cases, my data was imported and the DeviceRegistration table was created successfully. Perhaps you migrated with the help of some other archive, which is not in the original application, whose ID you wrote here (9FD83C1D-00B1-E549-FFAA-FC77B4421800)? If all the same you migrated using the archive for 1/25/2019, 4:30:47 PM or 1/28/2019, 6:36:48 PM, then I have another question for you, maybe you deleted this table?
I do not remember deleting the table. I don’t think I had any reason to delete the table. I am ok with restoring the table for the deviceRegistration from either of those archives as long as it doesn’t effect new data which has been accumulated in other tables since the migration.
I think the main thing now is that the table is in place to start harvesting new device id’s for future push notifications.
So from which archive did you migrate? From v1-data-2019_01_25_14_30_46.zip or v1-data-2019_01_28_16_36_47.zip
Unfortunately I cannot remember!
Does it make any difference except for losing some device ID’s ?
And I don’t know if this make any difference Vladimir, but I think the original migration went to:
App ID: 9197E805-6C48-0637-FFCB-1A5E8CF1FD00
but then I duplicated the above app to the current App which is
AppID : E9DF3457-FBDF-4D42-A6F3-FDFF2C260FF6
I can suggest you to do the following:
- Create a new empty application (myNewApplication).
- Import the latest data from your 3rd version application (v1-data-2019_01_28_16_36_47.zip (located 9FD83C1D-00B1-E549-FFAA-FC77B4421800 - Files - migration-to-4)) into myNewApplication.
- Make the latest export your data in version 5 - E9DF3457-FBDF-4D42-A6F3-FDFF2C260FF6 - Manage - Export (export_date1.zip).
- Import the file export_date1.zip into myNewApplication.
I made this sequence of actions. You can look at the result in the application 6D5870C9-F1F1-008B-FF30-6CCFFEE5AC00 - you are added there as a developer and have access to it. Does this result suit you?
Is it now possible now to bring that DeviceRegistration table you have created in this new version (ID: 6D5870C9-F1F1-008B-FF30-6CCFFEE5AC00: myNewApplication - Hastings2022 on my console?) into ApplicationID E9DF3457-FBDF-4D42-A6F3-FDFF2C260FF6?
I note that the size of the tables in this new application is double the size of the original tables, which I guess is due to duplication of some data, but if it is possible to import just this new DeviceRegistration table into ApplicationID E9DF3457-FBDF-4D42-A6F3-FDFF2C260FF6 then this is of no consequence.
Is this what you were thinking?
In fact, the amount of data in the tables has not doubled.
In some tables it has increased, but I assume that this is a consequence of the fact that there is more complete data, for example, the DeviceInfo table in E9DF3457-FBDF-4D42-A6F3-FDFF2C260FF6 contains entries created from 05/31/2019 11:00 : 35 to 05/07/2019 5:17:30 PM, but in Hastings2022 from 12/09/2017 10:21:16 PM to 5/05/2019 5:17:30 PM.
The DeviceRegistration table is system, not sure that even now it can be imported into the application E9DF3457-FBDF-4D42-A6F3-FDFF2C260FF6.
The LoyaltyPoints table in the newly created table has 268 pages of data where as the the LoyaltyPoints table only has 163 pages of data. The voucher table has also increased. Yes you are right with the DeviceInfo table as that does have more data.
But more importantly If we can’t import that table then it will mean that we will have to update all the apps to point to the new backend app which will be an absolute nightmare to us as we have just spent last 4 weeks updating them to point to this backend and migrating the data and we can’t afford to go through this process again.
Is it not possible then to create just a blank DeviceRegistration Table for this app?
06/28/2016 14:41:24 - 07/08/2019 10:50:04
05/20/2019 17:32:22 - 07/08/2019 10:50:04
But I understand what is the inconvenience for you here.
I will also consult with my colleagues how to solve your question.
Thanks Vladimir for your help in this matter