Ultra Recall search flaws?

Posted by karel
Jun 29, 2018 at 03:30 PM

Hi,

user 22111 complained about problems with Ultra Recall’s search (see an excerpt below) in this thread: http://www.outlinersoftware.com/topics/viewt/5136/30

I am on a verge of actually buying UR so I would like to learn more about this if there’s somebody who can comment, pls?
My needs are simple (considering I won’t get much anyway) - being able to search (incl partial search e.g. *linerSoftw*) in note titles, bodies and attributes/keywords. UR seems to be doing it ok. Where does its search fail, pls?

Thanks in advance for your kind help!

Best regards,

Karel

22111 wrote:
jimspoon wrote: “Infoqube and Ultra Recall are quite slow to sort or
>display a grid of thousands of items. I guess the key is to refine my
>search so that fewer items are displayed. The underlying database
>structure is obviously very different.”
> >I’ve complained about it elsewhere: UR does not “translate” the search
>functionality of its underlying database, SQLite (some other outliners
>do also use that since it’s free AND it’s real good, quite perfect for
>this task (desktop, not too much collaborative), entirely, but “shields”
>it from you.
> >And then, this is not new either, its search functionality is the only
>element of UR that is not rock-solid; in fact, search results can be
>unpredictable, which is one of the reasons I’m not so happy with it
>anymore, all the less so since the developer, while eager to de-bug his
>program any which way he can, does NOT do anything about UR’s search in
>spite of the reports about its problems he gets.
> >Now let’s see into this: If we hadn’t the tree frontends set upon those
>sql databases, but some classic frontend you would have for the bigger
>databases and which are often also available for SQLite, you could do
>SQL searches, instead, and we all know that here, mainly two, three
>factors concur to give you search speed:
> >First, the repartition of your data within the relational database. Of
>course, this is a design decision, here of the UR developer, and you
>cannot blame the underlying database for possible data repartition (I’m
>not saying you try to do this, I’m just speaking in general); also, one
>user needing particular searches often, is “offered” the “general”
>database architecture, not something adequate to his needs, as if he had
>set up the database himself, according to these.
> >Then, more or less parented to the first factor, is the maintenance of
>indexes, meaning, which possible info is indexed, which is not, and we
>recall UR does not offer any options here: Again, it’s the standard fare
>you’ll be served.
> >And third, we all know that there are often lots of different ways to to
>sql searches, very “dumb” ones - let’s call them “beginner style”, and
>then, very smart ones, that often might not be tenfold as fast, but
>hundredfold or even faster - or let’s say the “beginner style” can be
>very, very slow!
> >Now if you do sql searches, direct, you will “learn” from your response
>times, meaning if your search is too slow, you will try to find a better
>way to do the “same” search, and here, many web sites and advanced books
>on sql will be of big help (if you can justify the buying and reading).
> >Now back to UR. I strongly suppose its search panes (regular and
>“advanced”) do translate your search wishes, in the most inflexible,
>rigid, “stupid” way possible, into “dumbest” sql search commands, or
>let’s be nice and say, UR does standardize your sql searches to the
>core.
> >I’m perfectly aware that in such an environment, there are not 51
>possibilities, but there would be SOME possibilities at least, but which
>would need to be implemented and coded, and you cannot expect this from
>UR.
> >Technically, it’s perfectly possible to predict some MORE standard uses
>of the database, and to have at least additional indexes built and
>maintained by option. Then, it’s possible to introduce some more search
>search panes, not just “standard” and “advanced”, but to have several
>“advanced styles”, for different, typical tasks, and for which the
>translation into sql would be quite different = optimized for the main
>elements of your different searches, since of course, it’s quite another
>task to just combine different key words, or to select/sort by some
>attribute, and then only be interested in key words, to give an example.
> >And then, it also would be perfectly possible to implement “stored
>searches”... but for sql searches: Have a search “line” (in fact, since
>we’re speaking of sql, a search field with perhaps twelve lines) for
>entering sql blocks, and have a pane to which you can store, and from
>which you can then retrieve both stored searches with theirr content,
>and just skeletons, or combinations of real search “terms” and just
>empty command parts first to be filled up and/or to be adjusted to any
>new search, meaning you will store some dozen such sql searches, grouped
>by kind/complexity, and then retrieving one will place it into the
>search field, where you will probably want to do adjustments (or even
>not, for your most standardized, recurring searches), and then a key
>(perhaps a double return) would trigger your “optimized” sql search,
>optimized if you took the effort to optimize it.
> >Such an approach would also eliminate the unpredictability of UR’s
>current search, since you can be 100 p.c. sure that these bugs don’t
>come from SQLite, but from UR’s “translation services”.
> >And again, we face the old problem that we don’t constitute enough of a
>“market” in order for developers doing the work, and thus we live with
>sub-standards that technically could be easily avoided. We just ain’t
>worth it.
> >This reminds me of MindJet: In so many years, with so much money earned,
>they weren’t able to introduce inter-illustration clones, which for a
>mind-mapping system are so necessary though, since the philosophy beind
>mind-mapping is certainly not to create monster maps with 5,000 items,
>but to discard anything not relevant in a given context to another
>context, but since things are interrelated to other contexts, too, this
>supposes clones updated in different maps.
> >In fact, the absence of this feature invalidates the whole concept, but
>without them being bothered by such considerations. I say it reminds of
>MindJet since some days ago, I got a mail praising the newest version,
>now with a better database, of a macro program that tried to update such
>things, from the outside, in your MindJet map collection, be it for your
>own use of “cartography” of your things, or for collaborative tasks.
>This macro program, costing several hundred dollars, is expected to be
>run before 9 in the morning, then again around supper, and then perhaps
>again in the evening, instead of next morning before work: As said, it
>maintains its own database in order to do all this that should be done
>from within MindJet’s database in real time, from the outside,
>“manually”, when there is a break in your work.
> >So this ridicule is proof that our not getting needed functionality has
>not too much to do with our being too small a “market”, but if we were a
>great many (as paying MindJet users are), the return maximization
>efforts of the developers/suppliers would assure we didn’t get our
>needed functionality there either.
> >Technically, it’s almost always possible, and more often than not, it
>would be even rather easy to code. Evernote is a good example: It has
>certainly got some new, state-of-the-art functionality, so they prove
>they are technically able to do a lot of things, and then many “basics”,
>also needed, have even been eliminated, instead of having been developed
>to a higher degree.
> >Anyway: My starting point was, don’t blame the database here, blame
>stupid frontends.
>