Hi Graydon, that's interesting - my perspective is 100% different. I've been working with XQuery for 15+years day in day out, and my working with files is 99.9% of the time, working with databases 0.1%. (And that's a cautious estimate.) I work with a constantly changing set of document sets, I simply cannot afford the fuss of creating and deleting databases all the time. (It would be a downright waste of time - BaseX is so fast when dealing with the file system that the difference would be hardly noticeable.)
And how about tool writing? Would you ask the users to prepare tool use by loading files into a database? Or would you want to clutter up tools with the creation and deletion of auxilliary databases nobody needs, only in order to answer a question or report about what is there in the file system?
This shows that there are different perspectives.
Hans-Jürgen
Am Freitag, 11. Februar 2022, 22:11:57 MEZ hat Graydon graydonish@gmail.com Folgendes geschrieben:
On Fri, Feb 11, 2022 at 08:12:22PM +0000, Hans-Juergen Rennau scripsit:
Well, Liam, as I said - it can be done, my request is for supporting elegance. Here's the litmus test. How would you rewrite this little function ...
declare function f:docs($dir, $fname, $deep) as document-node()* { file:list($dir, true(), $fname) ! concat(file:resolve-path($dir), '/', .) ! (try {doc(.)} catch * {}) };
It's entirely likely I'm missing something here, but isn't the intent of this pretty much
db:create("DB", file:list($dir, true(), $fname), ())
where that third param to db:create lets you remap the path if required?
At which point the use case becomes db:open('DB')/*/@version => distinct-values() => sort()
In general, I don't want to have to think about files; it's great that the file module is there for those occasions where this cannot be avoided, but in general I want the XML loaded into a database (where someone with much better test cases has written the functions!) much more than I want to think about file system details.
What am I missing?