• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Question re: tInternalA["delaySend"]
#1
Hi LiveCloud team and all,

Quick question - several methods that update the cloud database have an option to defer the update until a cdb_flushCache is sent. Great and very useful for batching multiple updates to the cloud.

However just wanted to check - if i do an update or batchMerge and defer the cloud update by putting true into tInternalA["delaySend"], does this update the local database?

Or do I have to update the local database separately?  (needless to say i'd prefer the former!)

Many thanks
Stam
  Reply
#2
Hi Stam,

cdb_flushCache and pInternalA with a value of "delaySend" apply to cloud calls only.

One can not delay calls to the local database. The main reason for not supporting delays for local calls is because local calls are speedy.

We made the features for flush and delay for cloud calls because they are inherently slower and more prone to failures when compared to local calls.

-Mark
  Reply
#3
Hi Mark,
I get that - was just asking if the same call would immediately update the local database as well as push changed to the cache for delayed flushing...
Guess not... just means i have to add extra calls to update the local as well...

Thanks as always,
Stam
  Reply
#4
(07-01-2021, 02:11 AM)stamatis Wrote: Hi Mark,
I get that - was just asking if the same call would immediately update the local database as well as push changed to the cache for delayed flushing...
Guess not... just means i have to add extra calls to update the local as well...

Thanks as always,
Stam

Sorry about not addressing you question well. You are right in that the Target property applies to either 'cloud' or 'local'. We could consider a 'both' (complete, everywhere, local-cloud, etc) option down the road to make it a single call. 

Keep in mind that if you plan to write to both locations, recordIDs will be different. You can set the recordID to match the first call. Or, you can sync only the recordIDs from the first call. That would probably be easier to do.

Example:

cdb_create for the cloud is executed. Then, do a cdb_sync with cloud as the source. Pass the recordIDs that are returned to you from the cdb_create. This method will ensure that both sets are using the same recordIDs.

-Mark
  Reply
#5
(07-01-2021, 06:33 PM)mark_talluto Wrote:
(07-01-2021, 02:11 AM)stamatis Wrote: Hi Mark,
I get that - was just asking if the same call would immediately update the local database as well as push changed to the cache for delayed flushing...
Guess not... just means i have to add extra calls to update the local as well...

Thanks as always,
Stam

Sorry about not addressing you question well. You are right in that the Target property applies to either 'cloud' or 'local'. We could consider a 'both' (complete, everywhere, local-cloud, etc) option down the road to make it a single call. 

Keep in mind that if you plan to write to both locations, recordIDs will be different. You can set the recordID to match the first call. Or, you can sync only the recordIDs from the first call. That would probably be easier to do.

Example:

cdb_create for the cloud is executed. Then, do a cdb_sync with cloud as the source. Pass the recordIDs that are returned to you from the cdb_create. This method will ensure that both sets are using the same recordIDs.

-Mark

Very clear and helpful - thank you Mark
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)