+- LiveCloud Forums (https://forums.livecloud.io)
+-- Forum: General (https://forums.livecloud.io/forumdisplay.php?fid=1)
+--- Forum: General (https://forums.livecloud.io/forumdisplay.php?fid=3)
+--- Thread: newbie advice (/showthread.php?tid=461)
newbie advice - stamatis - 08-23-2020
Hi all,
Am just getting familiar with liveCloud and was hoping for some guidance:
1. When creating a record (cdb_create) you specify a target of 'local' or 'cloud'. What is the best practice to ensure 'cloud' data is synced when internet access is interrupted and then restored? Does any cached data survive past quitting and restarting the app?
2. Is it possible to have a local db that syncs with the cloud rather than directly CRUD'ing from the cloud? Cloud access seems very slow (on free version in any case) and i wonder if this may be way to speed things up.
3. On that note, all example I've tried apps are really quite slow - it takes about 10 secs to load the sample app and sync data and in general any data manipulation seems to take relatively long time giving the impression of a hung app. I imagine this is largely for apps storing data in the cloud. Is there a better practice to speed up access?
I haven't yet actually used liveCloud in any projects (currently SQL based) but investigating this for LiveCode based apps - grateful for any advice/guidance,..
RE: newbie advice - mark_talluto - 08-23-2020
Hi Stamatis,
First of all, welcome to the LiveCloud forums. I am happy to answer your questions.
1. To use the local, cloud, or a combination of both is a question that depends on the type of app you want to make. The system is very flexible. So you have many options.
For most apps, I would suggest storing data locally and syncing it up as you need. For maximum efficiency, you might sync only the records that have been touched by your software.
Tip: To determine which records have been touched requires running a query on your local metaData. Query the cdbDateModifed key. Have it return the cdbRecordIDs vs. the whole record. Then sync only those records with the cloud. *Use LCM to write the query code for you.
2. Yes, in the first part of the question. Cloud performance directly correlates to geography and network conditions. Try to pick the region closest to you. We would love to be able to put regions in every part of the world. It is one of our goals to build them out wherever our customers are. We do have two new regions being considered before the end of the year (Germany and Singapore).
3. Local access will always be faster than cloud access based on some of the conditions I presented above. Where are you based, and which region did you select?
RE: newbie advice - mark_talluto - 08-23-2020
I missed your question of cached data. All transactions that do not get sent to the cloud are cached automatically for you. Your next successful attempt to make a cloud transaction will flush your cache first to maintain order of operations.
RE: newbie advice - stamatis - 08-24-2020
(08-23-2020, 08:21 PM)mark_talluto Wrote: For most apps, I would suggest storing data locally and syncing it up as you need. For maximum efficiency, you might sync only the records that have been touched by your software.
Dear Mark, thank you for the advice - i just couldn't see how to do this automatically.
I can see how to create 'local' records - but what is the process to sync these to a 'cloud' target?
Is there a wholesale/automatic way of updating the cloud db from the local db?
(08-23-2020, 08:21 PM)mark_talluto Wrote: Tip: To determine which records have been touched requires running a query on your local metaData. Query the cdbDateModifed key. Have it return the cdbRecordIDs vs. the whole record. Then sync only those records with the cloud. *Use LCM to write the query code for you.
Good tip, thank you.
(08-23-2020, 08:21 PM)mark_talluto Wrote: Cloud performance directly correlates to geography and network conditions. Try to pick the region closest to you.
Yes i figured that - I am in London and am connecting to the London server... but performance isn't what i expected if I'm honest. I just wonder if it's something I'm not doing right on my end... (but I've basically tested this on unmodified sample apps on a fast Mac with fast connection, so it's not the set up on my end...). Or perhaps it's a side effect of the free tier which i'm currently testing.
I realise it's a lot of effort and cost, but some more tutorials or videos showing these techniques would be really helpful...
(08-23-2020, 10:57 PM)mark_talluto Wrote: Your next successful attempt to make a cloud transaction will flush your cache first to maintain order of operations.
Ah ok - having to successfully make a cloud transaction to flush the cache is what threw me.
Is there a best practice for this? Perhaps something in an 'on idle' handler?
RE: newbie advice - mark_talluto - 08-24-2020
You could get a better view of your connection by trying the following. Try cdb_ping() https://docs.livecloud.io/Ping/
and
cdb_pingNode() https://docs.livecloud.io/PingNode/
Please report back with your findings for both APIs. Thanks!
RE: newbie advice - mark_talluto - 08-24-2020
You can force the cache to flush at any point by calling: https://docs.livecloud.io/FlushCache/
Some like to call this on the start of their application. Others might suggest you do it at point where the app is being quit or closed.
I don't think you need it when you are in the middle of your app because all subsequent cloud calls will address cached data automatically.
RE: newbie advice - mark_talluto - 08-24-2020
Syncing your data can be done by many tables, one table, or a selected list of recordIDs.
Have a look at our docs on sync here: https://docs.livecloud.io/Sync/
This is a good place to start with sync.
There are 4 code examples that show a variety of use cases.
You may want to have a gander at batch sync here: https://docs.livecloud.io/BatchSync/
This API allows you to address multiple tables in a single call.