Hi Kristian,

It could be possible to swap the argument order if the argument types were disjunct. However, as xs:string is a sub type of item(), it is not possible to decide for a query like…

db:replace('db', 'a.xml', 'b.xml')

…if "a.xml" is supposed to be an input or a path. Does this make sense to you?

In the long term, I plan to introduce a new db:update function, get rid of db:add and db:replace, and disallow documents with identical database paths. Right now, I am aware of at least two use cases in which the fast addition of new documents is crucial, and in which the use of db:replace would be too slow. As soon as I find enough time to rewrite the database path index, and make it fast enough for millions of database resources, I assume that the two old functions could be completely dropped. This would have effects on all other API as well (such as REST, which is currently bound to using REPLACE).

Cheers, Christian

On Tue, Jan 16, 2018 at 8:53 PM, Kristian Kankainen kristian@keeleleek.ee wrote:

Hello

I once again ran into giving the arguments in wrong order to the db:replace function. The docs state, that "For historical reasons, the order of the 2nd and 3rd argument is different to db:add and db:create".

Since XQuery is typed, wouldn't it be possible to add to new "cosmetic" functions with the arguments in the "right" order like the following:

db:replace($db as xs:string, $input as item(), $path as xs:string) as empty-sequence() db:replace($db as xs:string, $input as item(), $path as xs:string, $options as map(*)?) as empty-sequence()

Since the arguments are typed with different types (xs:string vs item()) this over-loading would work without colliding with the historical and swapped ones. Am I wrong?

Cheers, Kristian K