|
Yes, that's what I meant, but I have to admit that now, by trying again, it's back to normal = expected behavior again, so that was my bad, sorry; I must have done something wrong.
On the other hand, I have spent some hours with trying to make the tree filtering functionality useful for me, to no avail; in order to see two flags and their occurrences in correct order, they would have to be all within the totally same "lineage" = the same long, very long siblings' list, and ditto for filtering by search, even with numerous tries with additional user attributes, it's all totally futile.
I then trialed some competitor, just for comparing, and what I found was hair-rising indeed:
Construction preservation seems to be absolute standard, default, both in flat-list form or in indentation-preserving = visual tree form.
Here's what I found - you will recognize the software, but I don't write this for advertising reasons:
"Global Search", then scope: In this section (would be a "tab" within the current db), In this notebook (=default, would be UR's current db), in open notebooks (= open DBs), in all notebooks; already scope-wise, this is perfect, and obviously, the developer took the additional effort to program the necessary code to gather the multiple SQLite indices, in order to make such scopes available to the user.
Then sorting, called "Group by": section (= default), title, date updated; title is titles by abc, date is dates by dates, and section is a flat list, preserving the construction order, in other words, not multiple sort orders, as in UR, are made available, just 3 fixed ones, but incl. the absolutely necessary construction order, which doesn't even have a name other than "section", so totally it's considered standard; then (not tried out), if you have scope db, open DBs or all DBs, the construction order in every section will be observed, just put one behind the other; also this would be user-side expected behavior.
I tried this with the search strings title:x (having added the x to just some titles), and with title:x OR title:y (having also added some y to other titles).
(Btw, I created my trial items in total disorder, in order to avoid a possible "by chance only" "tree order" sort which might have been produced by the creation order, and I added the x and y afterwards, also in disorder, so the program's "last change" date order doesn't play a role here, the default sort order is really the (current) construction order, nothing else.)
Then, I applied the same search strings (just x, or x or y, in the title) to the tree! Since the tree pane has a filter function, input field always visible, "Filter section notes", and here I was eager to see how the developer did the tree filtering (see a, b, c above): It's a simplified b over there, i.e. it's in tree form, together with the tree's indentations, and together with all necessary intermediates needed for showing ALL non-hidden items, i.e. there are no "filter orphans" over there, which, as we had to discover, are hidden-against-expectation in UR's tree filter.
Thus, the competitor does it all perfectly right, and even the tree filtering with any attribute or attributes combination, from the Filter field, so combinations could be automated by external macro, ditto for the Search field, whilst in UR, compound searches would have to be clicked-together (as described by me in another thread), which presents, for stored searches (which are possible in UR), the additional problem that it's then quite difficult to run those just with new values.
So now for the "bads" over there: I haven't discovered "flags" or any other way of formatting tree items (I mean the items' titles within the tree), and I absolutely love UR's way of doing that (now up to 20 formats ;-) ), in fact I can't do without, had tried for some time in some other software, NEED UR for this feature.
Also, with near half a million items in UR, I'm not ready to switch, that's for sure. On the other hand, I'm currently musing about switching to the other app just for that part of my work where I would need correct construction preservation in item filtering, not even filtering by more than one criterion, but by more than one VALUE or the same criterion (here: flag = red OR green, i.e. show both, and all of them, and in the correct order); I'm hesitating because I would then, for that part of my work, lose the aforementioned "tree formatting" for different kinds of items; I could (easily, as described) filter for them, by tags (which are available there) or simply by title tags (like my trial x and y), but UR's fine "distinguish'em by a glance" would be gone, and that would be, in my case i.e. from my needs, more than awful, even and also in that part of my work.
Btw, when I say "order preservation is (to be considered) standard", it's not just for what I just discovered within the competitor's search and tree filter, but it's how the search results are presented in any editor, any dedicated search tool (provided they come with a line view of all hits) by default: in their original occurrences' order, from first to last line of the text body, and any "grep" does work that way.
Thus, UR's omission of that "natural sort" obviously is very non-standard, AND a real problem; btw, with my (systematic) lineage-then-treeorder sort (which was deemed to be "tree order", since we believed the linked threads' allegations), I never succeeded in finding the relevant positions within the tree (Data Explorer) on my own, just from visually navigating from search result table to Data Explorer (which would have preserved the search result table), but had to press Enter on one of the results in the results table, in order to navigate there, and which then destroyed the results table (just navigating within the results table will only display the respective content, but will not "situate" the item within the tree): no wonder, since the results in the results table, deemed "in tree order", were sufficiently "mixed up", in order to lead me astray.
And that (not assuming the results were not in correct order, so no systematic check, verification, and the disappearance of the result table whenever I then navigated to the item in question) was responsible I lived with that for quite some time... whilst my current combination of TWO flag values, one for construction and one for the items-of-interest in that filter / search, I immediately discovered that tree-order is not.
I don't know if the competitor also applies (your) adjacency list model, or some path model, but I assume it's in your interest to check how he does it, SQLite-table and -columns-wise, in order to not encounter your coding problems for preserving tree order in search and filter results.
As for possible speed problems, I admit my trial db over there had less than 20 items, not 30,000 or more, as some of my UR DBs do, but above, I had said, in my first, and then again, more to the point, in my intermediate post, "(I also said the additional code, with the creation of the intermediate SQL "view" from which then the "hierarchy sort" is done, should, of course, only [be] triggered whenever the option "preserve structure" has been set for the search / filtering [in question].)" - so perhaps, speed problems would not need to spread all over the place, or then, some modification of the Adjacency List model might do it, even if that then (necessarily) slows down moves of whole sub-trees (which don't occur that often after all, once the users will have "organized themselves somewhat") a little bit?
Let me say here that I admire your solution how you have implemented (item, and whole sub-structures') cloning, from what I from your tables and your columns: That's really ingenious! So it would be quite a pity if you coudn't also find a viable solution for the - as alleged by me - standard tree preservation in search, and filter, results? ;-)
|