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.