Delayed effect of create and update functions in the API

flyingdutchie

Hi Smugmug (David),

When i do a create or an update (changeSettings, rename, etc) on an object (category, subcategory, album, image, etc) and immediately after that a get or a getInfo, the updated information is not found.

E.g (in pseudo-code)

Issues with create:

object = smugmug.object.create(...)
allObjects = smugmug.object.[B]get[/B]();
testObject = allObjects.find(object.id);
// Sometimes testObject is null (allObjects did not contain object).

Issues with update:

object = smugmug.object.create("TestName");
...
...
...
object.name = "TestName2"
object.update() // e.g. changeSettings, rename
object.[B]getInfo[/B]() 
 
testName = object.name;
// I expect testName to be "TestName2", but sometimes it is still "TestName".

When i put a pause just before the get() or before the getInfo(), it may work. Sometimes it still doesn't work, and i have to make the pause longer.

Question:
Can it be fixed so that the new and updated objects are immediately ready for retrieval (or at least have the get() or the getInfo() wait until that updated information is available)?

-- Anton.
PS: I'm using JSON API version 1.2.0 (Riyad's API).

devbobo

G'day Anton,

DB replication is not syncronous, so some of our DB slaves could be out of sync by up to a few seconds.

This could be handled one of two ways, putting an additional timeout on SmugMug's end before returning the response, or you (3rd party developers) catering for this timeout period in your own app.

Personally, I prefer the latter.

Cheers,

David

flyingdutchie

devbobo wrote:

G'day Anton,

DB replication is not syncronous, so some of our DB slaves could be out of sync by up to a few seconds.

This could be handled one of two ways, putting an additional timeout on SmugMug's end before returning the response, or you (3rd party developers) catering for this timeout period in your own app.

Personally, I prefer the latter.

Cheers,

David

Thanks David,

That would not be a problem, if we know what the (maximum) length of time-out is. 1 sec, 2, 3, 10 secs...?

devbobo

flyingdutchie wrote:

Thanks David,

That would not be a problem, if we know what the (maximum) length of time-out is. 1 sec, 2, 3, 10 secs...?

well, I ran into this problem a few months ago when creating categories with SmuggLr and I found that a delay of around 2-3 seconds was sufficient in that situation.

You may need to do some testing with different values to see how it works out for you.

Cheers,

David

mouellette

devbobo wrote:

well, I ran into this problem a few months ago when creating categories with SmuggLr and I found that a delay of around 2-3 seconds was sufficient in that situation.

You may need to do some testing with different values to see how it works out for you.

Cheers,

David

Is this why I can't retrieve image info after uploading a new image sometimes? Sometimes when I load an image, and then getInfo on the image it says the image does not exist. This seemed to be more of an issue a week or two ago then now. I put in a loop to wait up to 1 minute for the GetInfo to respond. And it typically takes between 10 and 20 seconds before I get a valid response. This never seemed to happen before. I wrote another thread on this issue as well.

pe2smugmug

devbobo wrote:

well, I ran into this problem a few months ago when creating categories with SmuggLr and I found that a delay of around 2-3 seconds was sufficient in that situation.

You may need to do some testing with different values to see how it works out for you.

Cheers,

David

I had this same problem when setting up unit tests for my library (lots of create, check, update, check, delete, etc). I have found that about 90% of the time waiting 5seconds worked, but that to make it 100% reliable, I changed the wait time to 10sec. The speed of updates seemed to really depended upon the day, since unit tests are not really time critical, I just went with a nice round number that has yet to fail.

There was a thread on this problem elsewhere (can't seem to find it now), and one solution for created items was to setup a little loop that checks every second, with a timeout at say 10seconds; to minimize the delay in the application. Obviously this doesn't work as well for updates, but its one approach for creates.

devbobo

mouellette wrote:

Is this why I can't retrieve image info after uploading a new image sometimes? Sometimes when I load an image, and then getInfo on the image it says the image does not exist. This seemed to be more of an issue a week or two ago then now. I put in a loop to wait up to 1 minute for the GetInfo to respond. And it typically takes between 10 and 20 seconds before I get a valid response. This never seemed to happen before. I wrote another thread on this issue as well.

This issue popped up after I tightened the code to prevent returning responses for deleted images, but it happened to also exclude images in the 'Preprocess' state. I subsequently fixed it to return results for images in the 'Proprocess' state, so I believe that the smugmug.images.getInfo method should be returning responses as it previously did. Can you please confirm that ?

Cheers,

David

flyingdutchie

devbobo wrote:

This issue popped up after I tightened the code to prevent returning responses for deleted images, but it happened to also exclude images in the 'Preprocess' state. I subsequently fixed it to return results for images in the 'Proprocess' state, so I believe that the smugmug.images.getInfo method should be returning responses as it previously did. Can you please confirm that ?

Cheers,

David

Thanks David,
i will check it out this evening.
However, i've seen this on other objects than images as well. This problem occurs as well with categories, subcategories and albums.

devbobo

flyingdutchie wrote:

Thanks David,
i will check it out this evening.
However, i've seen this on other objects than images as well. This problem occurs as well with categories, subcategories and albums.

Anton,

That response was for mouellette, his issue is different to what you are seeing.

David