IMWS.post('v1/metadata/writeback' question

[ubacher]

For

Code Select Expand

IMWS.post('v1/metadata/writeback' the documentation says

If background write-back is disabled in IMatch, this endpoint has no effect.

I assumes this refers to the setting
Write-back changes to metadata immediately
But if this is set it should write it anyway without needing any scripting. I will want to trigger the write-back if it is not set to automatic.

Confused!

[Mario]

This endpoint puts the files you specify in the background write-back queue. It would be impossible for a web request to wait for a write-back to complete. The web server will run into timeouts and cancel the request. If background write-back is on, the queue is processed.

This endpoint is more targeted at being used in IMatch WebServices. Not in IMatch.  In IMatch the user controls when to write back. Not a script.

[ubacher]

In IMatch the user controls when to write back. Not a script.

But the purpose of scripting is to automate some functions.
As it is then, I can automate the updating of the metadata but not the afterward necessary write-back.
Could I run a command to initiate the write-back?

Should I put in a feature request?

[Mario]

This command initiates the write back in the background. There is no synchronous function which waits for a Write-back to continue. When you issue the command, 1000 other files may already be in the queue, writing back data to files.

[ubacher]

Is there any way to initiate a writeback if one does not have background write-backs enabled?
(Is this functionality still on the to-do list?)

[Mario]

See release notes for IMatch 2017.9.2 item  #00284

I can only urge users who write scripts to study the release notes of each release carefully.

Changes relevant to developers are marked with @Developers and I reserve the right to (occasionally) introduce breaking changes in existing APIs for good reasons.
You definitely want to know about this, or changed or new endpoints.
I don't spend the time writing the release notes for nothing, you know.

The only way I can community changes like this, or changes in general, is via the release notes.
I assume that all users read them before using IMatch.

[ubacher]

Thanks. I had missed this.

The documentation needs updating: it still says if writeback is disabled it has no effect.

[Mario]

Thank for your telling me that some sentence in the documentation is wrong.
Since IMatch ships with a ton of documentation (plus the developer center), which documentation do you mean, exactly?

I think you mean I should update the endpoint documentation for the /metadata/writeback endpoint?
And you want me to include something like "except you specify the immediate parameter below as true."
I can do that. But it is always helpful when a user not only reports that somewhere in the documentation something is wrong or missing - but also where.
Saves me a few minutes Adds up quickly.

Pay especial attention to the warnings in the documentation of immediate.
Using immediate should be the absolute exception. And only if very few files are affected. Using this can break IMatch, can spoil the write-back, can cause other database transaction to abort because they cannot lock the database etc... Don't overuse this. If you use this from your App, you take full responsibility.

[ubacher]

Using immediate should be the absolute exception

Is that different than in IM5? I assume if I use it just like in IM5 I am OK.
My only alternative is to present the files to be re-written in a result window, selected, and have the user (me) initiate the rewrite manually!

Screen shot about the extra sentence in the docu is attached.
Documentation: obviously I meant the documentation for  /metadata/writeback.