SkyVia Replication Breaks when Column is Removed from Salesforce Object Being Replicated

  • 67Views
  • Last Post 22 March 2018
0
votes
API User Reporting posted this 16 March 2018

Greetings:

There is a critical bug in SkyVia Replication with respect to removing columns from a replicated Salesforce object. 

First off, you should not be automatically adding new object columns to a replication package. If you want to expose them on the UI pending the user's selection of such for including the column in the object replication, this would be acceptable. Automatically adding new columns is a breaking change because the target table does not have the column defined. This needs to be addressed.

Secondly, any attempt on our part to remove the column from the replication causes us to have to re-sync the package. This should not be the case. This needs to be addressed

Additionally, if we remove a column that is being replicated from an object this causes a failure in the package. And we cannot go in and remove the column from the package because to do so would cause us to have to re-sync the package. This is not acceptable. 

To reiterate, you should not be automatically adding new object columns to replication.

You should allow columns to be removed from a package without requiring a re-sync. Think about it. You don't need to re-create the table. DML Updates don't require the column to be present. DML Inserts only require the column to present unless there is a constraint requiring such.

Please advise.

Respectfully,

Darryll Petrancuri

P. S.

Our confidence is greatly diminished. To be candid, we continue to use SkyVia at this time due to budgetary constraints. This may not continue to be the case in the future when budgets are under review if serious effort is not put into addressing the problems we have identified and you become much more transparent and forthcoming in discussing the issues presented at a technical level. I would like to hear from Simon on each of the issues presented and would like to know what will and won't be addressed, along with a projected timeline for each that will be addresed. Frankly, these errors are indicative of grossly inadequate testing, and more.

 

Order By: Standard | Newest | Votes
0
votes
Simon Bubnov posted this 20 March 2018

First off, you should not be automatically adding new object columns to a replication package. If you want to expose them on the UI pending the user's selection of such for including the column in the object replication, this would be acceptable. Automatically adding new columns is a breaking change because the target table does not have the column defined. This needs to be addressed.

 

We are very sorry for inconveniences. We have reproduced the issue. We will notify you when the bug is fixed.

 

Secondly, any attempt on our part to remove the column from the replication causes us to have to re-sync the package. This should not be the case. This needs to be addressed

 

Additionally, if we remove a column that is being replicated from an object this causes a failure in the package. And we cannot go in and remove the column from the package because to do so would cause us to have to re-sync the package. This is not acceptable.

 

At the moment, when you add or remove a column from a replication package, its LastSyncTime value is reset. We will investigate the possibility not to reset LastSyncTime value if a column is added or removed from a replication package. We will also investigate the possibility to use the alternative method that you offered with calculating MAX(LastModifiedDate) in the target table. We will post here about the results.

 

Our confidence is greatly diminished. To be candid, we continue to use SkyVia at this time due to budgetary constraints. This may not continue to be the case in the future when budgets are under review if serious effort is not put into addressing the problems we have identified and you become much more transparent and forthcoming in discussing the issues presented at a technical level

 

Please kindly accept our sincere apology for the lack of support you encountered. We're now working on expanding our technical support capacity so we'll do our best efforts in order not to disappoint you again.

0
votes
API User Reporting posted this 20 March 2018

Simon:

It's not just a lack of support. It's a lack of engineering. There's a big difference.

Also, it's should be MAX(SystemModStamp) and not LastModifiedDate since it's well established that LastModifiedDate is not guaranteed to be updated at all times where SystemModStamp is.

Respectfully,

Darryll Petrancuri

0
votes
Simon Bubnov posted this 22 March 2018

Our project manager found your suggestion reasonable, and we have decided to change Skyvia's behavior. We won't reset LastSyncTime automatically if a replication package schema is changed. Instead we offer choice to the user - whether to reset it in order to re-create schema in the target and perform a full resync or not to reset LastSyncTime. In the latter case, the user must make the corresponding changes to the target database table himself. For example, if the user excluded a NOT NULL field from replication, the corresponding column must be deleted from the table. If the user selects a new field, the corresponding column must be created in the target table.

We will post here when this feature is implemented.

Close