Idea ID: 2809671

Redesign svc_import to to allow import operations while SM is running

Status : Waiting for Votes
Waiting for Votes
See status update history
11 months ago

Right now mechanism for importing data from XML files will call “DELETE”, then “INSERT” objects in DB for corresponding tables. It is not using internal SM logic (like for example when we are uploading data via unloads) and working directly with DB. To apply changes it is required to restart SM.

This results into the following problem for customers: they can’t use their DevOps mechanism to deliver "small" changes from DEV to PROD on fly as it will require SM downtime. The only available option for such "small" changes is to apply them using unloads mechanism of SM which makes it hard to track them as such changes aren't using DevOps release control workflow. 


  • Here I would like to add one scenario where updates delivered via svc_import wouldn't be consistent until SM restart.

    There are 50+ tables Query Results would be cached by default in SM (we can control this list with dbcachequery and filesnocache parameters), if we'll modify one of those tables via svc_import, end users will still see old cached data until SM wouldn't be restarted and cache wouldn't be cleared i.e. we will have inconsistent data in SM until restart. Having svc_import running updates directly at DB layer wouldn't allow to add a trigger to clear cache for specific table once it is updated via svc_import. Since we've added Feature Tracker into OOB 9.70 I would expect a lot of customers will start to use it and necessity of SM restart will result into bad user's experience with the new feature.