Hi Tim,

>One small UI change that would make a big difference (to me) would be to provide a drop-down option for files in the Editor (à la oXygen XML Editor)

It would be good, but seemed to run into some Java Swing issues when suggested before [1]

/Andy

[1] https://github.com/BaseXdb/basex/issues/1378#issuecomment-345750203

On Fri, 8 Apr 2022 at 18:37, Majewski, Steven Dennis (sdm7g) <sdm7g@virginia.edu> wrote:

Thanks!

It looks like using the filter button gets me most of what I wanted.

I can run commands from an editor file, click filter button ( assuming it’s XML results ),

And make further queries on that output as the context item. 

I’m building a series of complicated queries to generate a report from subsets of my database. 

Database is about 25K EAD files from various sources, so the encoding standards and conventions vary, so I’m having to check some of my assumptions as I go along ( like, for example, that IDs are correct and no duplicated within a single source/institution ). 

I’ve also been trying to figure out how to use unit tests to embed some assertions into the module.

It was a little confusing initially as the test button on the editor tab didn’t seem to work. 

Eventually, I discovered that I had to save the file before it would function properly. 

I suppose I’m trying to use the unit module in a rather untraditional manner.

Since running the tests is a completely different operation from running the query, it wasn’t initially clear that the other operations in the prologue are evaluated, but that does appear to be the case, so it looks like I can use that to test assertions on my various subsets of data before running queries. ( At least, I hope this is how it works! )

BTW: Here’s what I get with 9.7 on my Mac (OS v11.6.4), selecting an .xml file. 

On Apr 8, 2022, at 10:19 AM, Christian Grün <christian.gruen@gmail.com> wrote:

Hi Steven,

Thanks to Hans-Jürgen, the "Set as context" menu item was introduced just recently. 

And thanks to Tamara: Creating intermediate databases is exactly what I do, too. If the query output is a valid XML document, it can also be stored by clicking on the “Save” icon in the result view panel.

> I get a shorter menu of options that what’s shown in that doc:

The OS shouldn’t matter. I have Windows, but I’ve just been forwarded a 9.7 Mac screenshot (attached to this mail), and it looks correct. Can anyone else confirm that the menu is not completely shown on a Mac? Do you possibly get output some unexpected errors when starting the BaseX GUI from command line?

There is another built-in option to bind the result of a query to the context. It works if you have a database opened and if the query results are nodes from that database. We called the feature “Filter” (the possibly suboptimal term is because this feature was added 15 years ago; at that time, BaseX was limited to a simple XPath implementation). If you open a database and run a query that yields database nodes as results, you can press the filter icon: Your next queries will be based on these results, and all visualizations will adapt to show the result nodes on top level. With the arrow buttons in the menu bar, you can navigate between the previous and next result sets, or you can jump one level up (the parent::node() step will then be applied to all nodes in the result set) or back to the root nodes.

Maybe we can generalize the filter feature to work on arbitrary results, no matter what data type they have. One challenge here is that intermediate results can get fairly large, so we shouldn’t include them in the history. Next, if the results belong to arbitrary database nodes, we’d need to create main-memory copies from these nodes or ensure that the context is invalidated once a referenced database will be updated or deleted. Next, we’ll have to take care of … Alright, I’ll stop ;)

Further suggestions are welcome.

Best,

Christian

> On Apr 7, 2022, at 1:25 PM, Tamara Marnell <tmarnell@orbiscascade.org> wrote:
>
> Hi Steven,
>
> To save a few clicks, you can create a new database directly from your results in XQuery, without saving them to a file first. Instead of returning the results outright, assign them to a variable to pass as the input to db:create() in the return, with a made-up file name for the path.
>
> let $results := <results>{
>   [Your original return in here]
> }</results>
> return db:create('my_results_db', $results, 'my_results.xml')
>
> Then you can run further queries using db:open('my_results_db')/results, and DROP my_results_db in the command input bar when you don't need it anymore.
>
> This isn't to say a new feature isn't a good idea, just that there's a way you can streamline your workflow before that feature exists!
>
> -Tamara
>
>
>
> On Thu, Apr 7, 2022 at 9:49 AM Majewski, Steven Dennis (sdm7g) <sdm7g@virginia.edu> wrote:
>>
>>
>> It would be handy if there was a way to bind results to current context for additional inspection/investigation/query of results. Currently, it seems, you would have to save results to a file and then create database from that file to make an additional query on results.
>> That binding would be available from editor or input bar.
>>
>> Or perhaps alternatively, it could include an option to base visualizations on results instead of open database — although I’m guessing the former would be easier to implement than the latter.
>>
>> — Steve Majewski

<mac.jpg>