Search results not mixed-up anymore

[m248]

It might have occured to some that MyInfo, UR*, RightNote, MyBase, NoteCase Pro, etc., all mix up their search results, i.e. allow for some "sort", but do NOT respect tree-order, obviously since their SQLite back-end organization does not allow to write a select which would output the results in tree order per se (underwhelming sorting being the weak spot of SQL select in general); on the other hand, some simple lines of non-sql code, processing the (thus necessarily mixed-up) SQL output, would resolve the problem, in cases the user needs the tree order to be preserved - since the necessary information, to be then processed by the non-SQL code, is there, i.e. can be retrieved (=just not also be sorted correctly) by the SQL select.

*= They pretend (in several threads in their user forum) that their "lineage" = path sort will preserve the tree order, but that's unfortunately not true; pretext for refusing to add the additional code, even just optionally, being that re-sorting even just some dozen of mixed up search results would take ages (= in fact less then the tenth of a second on any pc working with current apps), and that the user would not accept that wait; in reality, out of the 5 apps mentioned above, just MI in in some current development...

and if some jamals chime in, telling us (even optional) tree preservation not being necessary, and what the "norm" was anyway: The only Windows app of this sort, and known by me, being Scrivener...

the sales of which might be tenfold of the combined (sic!) ones of the 5 apps mentioned beforehand, so listening to sensible suggestions might not be the worst idea a developer could get**; obviously, Scrivener is not robust enough for extensive data sets, so...

By tree preservation, I mean the usual flat list representation, obviously, but which first presents search results located deeper within the hierarchy, before listing the next item of the some hierarchy, e.g. in
(0) source
_(1) something with apple
__(2) another thing with apple
_(1) and a third thing with apple
the search for apple would list the results in order 1, 2, 1, and not mandatorily in order 1, 1, 2 anymore.

And yes, there are some other reasons why Scrivener has appropriated the non-online market (there must be some 10 books, even in print, about it), e.g. an easier way to rename terms (i.e. "global search-and-replace"), the lack of which are minor deficiencies of the 5 apps aforementioned (since the "pro" user can overcome them by their own means when - on rare occasions - such functionality would come handy, had it been implemented (as it has, in Scrivener)), but the mix-up of search results severely devaluates MI and its aforementioned contenders: It costs the user many seconds, every some minutes: It's un-professional like hell, whatever jamals' "norms" might be.

(Oh, and should some be reminded, again, that IM isn't about hoarding data, but is done in order to re-access it (called "retrieval")? ... and possibly in technically optimized ways since otherwise, paper would do... and certainly the IT should not scramble your retrieved data, as it has become the silly "norm" here...)


EDIT: I should have mentioned MI's tree-filtering in this respect, but since I mention it now: It unfortunately comes with severe limitations: It just filters by one (sic!) search term which must appear within the items' titles, so it does not replace general search / filtering, and even when the user tries to adapt to the "title terms only" limitation, by putting their tags within the titles, they will quickly discover that, as already said, this functionality is limited to a single search term (within the titles, as said), so you could not filter by combinations of tags, let alone any Boolean combination of them (AND, OR, NOT, and not even speaking of grouping/parentheses here)... and that severely hampers its usefulness for real-life scenarios - otherwise, it would have been - or could always become!!! - an extremely helpful feature indeed.

[Telesto]

EDIT: I should have mentioned MI's tree-filtering in this respect, but since I mention it now: It unfortunately comes with severe limitations: It just filters by one (sic!) search term which must appear within the items' titles, so it does not replace general search / filtering, and even when the user tries to adapt to the "title terms only" limitation, by putting their tags within the titles, they will quickly discover that, as already said, this functionality is limited to a single search term (within the titles, as said), so you could not filter by combinations of tags, let alone any Boolean combination of them (AND, OR, NOT, and not even speaking of grouping/parentheses here)... and that severely hampers its usefulness for real-life scenarios - otherwise, it would have been - or could always become!!! - an extremely helpful feature indeed.

I didn't test very complex search query's. However the tree filter isn't limited to Title only, except if you configure it that way. Boolean searches are working too. Or at least the basic ones

Record_2025_06_07_21_14_23_191.gif (300.18 KiB) Viewed 1897 times