From: "Frank Ch. Eigler" <email@example.com>
To: Mark Wielaard <firstname.lastname@example.org>
Subject: Re: PATCH: Bug debuginfod/29472 followup
Date: Thu, 10 Nov 2022 12:12:17 -0500 [thread overview]
Message-ID: <20221110171217.GD9668@redhat.com> (raw)
> Are you sure the interface is correct?
Hard to be sure, so it's left generalized. The APIs would be
unchanged if future search strategies are added (or subtracted);
they'd affect the choice of acceptable KEY strings.
We know we want glob patterns over executable file names. I've seen
cases where an exact match query produces a different sqlite query
plan from the glob one, but not sure how much performance difference
that implies. Searching for source files by glob/match is removed
from today's version because it doesn't run fast enough (without a new
> Is the sqlite "glob" pattern standardized?
> Can it be provided if the underlying server database isn't sqlite?
Yeah, in that unlikely case we undertake this someday. glob
expressions can be translated to regular expressions, which are
themselves supported in postgres & mysql.
> I haven't read the whole diff yet. There are several refactorings
> which would be nice to see a separate patch.
One such part that occurs to me is the debuginfod_query_server() ->
init_handles() / perform_queries() subdivision. Are there others?
> Why does debuginfod-client.c use json-c? Can't the server sent the
> json object as a normal char string? Why does the string from the
> server need to be interpreted as a json object and then turned into a
> string again?
Use of the library allows robust processing (checking & merging) of
incoming json data from multiple upstream servers. Luckily, json-c is
a small & self-contained library.
next prev parent reply other threads:[~2022-11-10 17:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 14:43 [Bug debuginfod/29472] New: Support querying the debuginfod-server for metadata rgoldber at redhat dot com
2022-08-12 9:05 ` [Bug debuginfod/29472] " mliska at suse dot cz
2022-08-12 9:05 ` mliska at suse dot cz
2022-08-22 18:24 ` rgoldber at redhat dot com
2022-08-31 14:52 ` rgoldber at redhat dot com
2022-09-02 17:25 ` rgoldber at redhat dot com
2022-11-01 14:23 ` PATCH: Bug debuginfod/29472 followup Frank Ch. Eigler
2022-11-01 22:20 ` Mark Wielaard
2022-11-10 17:12 ` Frank Ch. Eigler [this message]
2023-03-01 23:32 ` Mark Wielaard
2023-02-28 22:21 ` [Bug debuginfod/29472] Support querying the debuginfod-server for metadata mark at klomp dot org
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).