Tooling API – how to use LastSyncDate?

Question

Based on the documentation LastSyncDate can be used as a safeguard to ensure that when someone else modified Apex Class in SFDC you do not accidentally overwrite those changes using your older local version.

Tooling API documentation states following about LastSyncDate field

When you deploy a MetadataContainer, this value is compared with the LastModifiedDate of the underlying Apex class. If LastSyncDate is older than LastModifiedDate, the deployment fails with an error.

If I am reading it right then I shall include (set) LastSyncDate on ApexClassMember every time when I deploy that ApexClassMember as part of MetadataContainer. However if I specify any value of LastSyncDate and then I always get this error message:

Unable to create/update fields: LastSyncDate. Please check the security settings of this field and verify that it is read/write for your profile or permission set.

Obviously this tells that I am trying to update the field which can only be Filtered or Sorted, but other than directly setting LastSyncDate on ApexClassMember I can not figure out any other way to provide LastSyncDate as part of my deployment package.

(Using SOAP version of Tooling API v28)
Here is the sequence of steps (ignore the syntax):
//assuming I have created ApexClass previously and now have its Id, let’s call it “objectId”

1. Create Metadata container (this gives us containerId)
2. Instantiate ApexClassMember like so
   

   member = new ApexClassMember ()
   member.setContentEntityId(objectId)
   member.setBody(someClassBody)
   member.setMetadataContainerId(containerId)

3. member.setLastSyncDate(someDate)
4. Post ApexClassMember to SFDC
   sfdcToolingConnection.create(member)

If I skip step 3 then class body update succeeds, but if I include step 3 then system always returns the above mentioned error.

I am sure I am doing something wrong, but cannot figure out what this may be. Extensive googling did not return any examples of LastSyncDate usage in any shape or form.

Any hints will be very much appreciated.

Answer 1

LastSyncDate is not for manual setting. This field used in Metadata container to compare the time between components updated by two processes.

When you deploy component by metadatacontainer it compares the component with last sync date, if some one from other side updated the same component before you than its last modified date will be newer than your sync date and deployment will fail.

LastSyncDate and LastModifiedDate will be equal if you update some component by Tooling API. using ApexClassMember. Now if another user changed the same class from browser, after that you tried to sync by Tooling API, in that case deployment will fail as LastModifiedDate is newer than LastSyncDate.

Reference not saying to set LastSyncDate it get set automatically as your sync by Tooling API completes. It is used internally to prevent writing old code and losing the new one.

Answer 2

This was too long for a comment, so posting as an answer with some of the mentioned information from the other post.

Reference not saying to set LastSyncDate it get set automatically as your sync by Tooling API completes. It is used internally to prevent writing old code and losing the new one.

Correct. This is the intended function.

(B) Tooling API does not behave as documentation suggests (a bug?);

Yes, there is a bug that prevents this from working. It was fixed in Spring'14, so if you are in a DE org this will still fail. I don't think there is a known issue posted.

In Spring'14, you should be able to go through your process:

1. Update a container (will assign the LastModifiedDate of class to the LastSyncDate of container).
2. Update the class through the UI.
3. Deploy container (deploy will fail).

Note however, that the deploy will go through if you update the container with old source after the class has been updated. For example:

1. Create a container with the source from a class
2. Update the class through the UI.
3. Update the container with new source based on the old source from the container (now the LastSyncDate will be from the LastModifiedDate from 2.)
4. Deploy container (deploy will succeed)

It works that way so when the first flow hits the error, it can pull the updated source, merge them in the existing container, and deploy the updated changes. In other words, it is giving the power to the developer to handle that case.

I personally think that the LastSyncDate should only be set when the container is created, and updatable by the user. This would allow for the previous flow, but instead the deploy would fail. Then the developer will need to either:

• Update the LastSyncDate to allow the container to override the class.
• Create a new container, which would have a similar result unless the source was pulled from the updated class.

I would love to hear what your doing with the Tooling API.