Our current usages consume between 200 and 300 input files, so we'll still hit the 2^15 unique name limit.
Thanks; to get an even better impression: can you estimate how many distinct names you'll get in total? I remember one other use case in which we had to handle around 25,000 names (in most other cases, there are <100 names, which is why we still have that limit).
The multiple databases approach works, so I'll continue using it. It's just challenging to maintain. The main problem is that the internal BaseX API is really designed around having one database open at a time - or at least it was.
Yes, it still is.. and it might change at some time in future, but not probably not this year. Instead, we'd rather continue to extend the current limits to support TB-scale database instances (including more generous limits for element names).
In my recollection, while you can obviously query multiple databases using collections and other XQuery functions you've built in, the Context is designed to have one of them appear as "more important" than the others. However, my understanding was never all that good and/or this may have changed since I last looked at it in-depth.
It's pretty good indeed; the main database context was introduced to simplify database operations on command level, whereas XQuery allows you to access an arbitrary number of databases within the scope of a single query. With BaseX 6.7.1. or 6.8, we'll introduce additional custom XQuery db:...()-functions, which can then be used to perform batch operations on several databases.
Can you help me understand the current relationship between Context.datas, Context.data, and querying.
Context.datas is important in the client/server context: each client is allowed to open its own database, and the Context.datas object remembers how often each database has been referenced (pinned). In the standalone/embedded context, each database will be pinned at most once.
Hope this helps, Christian