From: Milan Zamazal <pdm@zamazal.org>
To: Peter Novodvorsky <nidd@altlinux.ru>
Cc: gnats-devel@sources.redhat.com
Subject: Re: modular database backends
Date: Sun, 17 Jun 2001 12:26:00 -0000 [thread overview]
Message-ID: <8766dvxqk9.fsf@blackbird.zamazal.org> (raw)
In-Reply-To: <3B27A419.2060703@altlinux.ru>
>>>>> "PN" == Peter Novodvorsky <nidd@altlinux.ru> writes:
PN> Milan Zamazal wrote:
>> - Maybe it's not *necessary* to force backends to implement full
>> query handling. We probably can agree on that writing new
>> backends should be as simple as possible. I can imagine that
>> your `query_pr' function could be only optional and there could
>> be available simpler versions of query functions that can get a
>> list of all problem IDs, a particular PR and maybe also
>> optionally some index (similar to the current one).
PN> We can implement simplier functions in library that will open
PN> this module. And these functions will use query_pr as more low
PN> level function. Any objections?
I'm not sure we understand each other. To clarify the things: For
instance, we could make a backend library that defines three functions
query_pr, get_list_of_pr_ids, get_pr. query_pr is implemented in the
library using the other two functions and those are implemented using
query_pr. Every backend must provide its own implementation of either
query_pr or get_list_of_pr_ids and get_pr, the other functions may (but
needn't) be implemented using the library.
So a backend powered by a sophisticated query engine (e.g. SQL) can
implement the complex query_pr function itself and needn't bother to
implement the simpler functions get_*. On the other hand, a file system
backend would implement the get_* functions and use the library function
for query_pr.
OK?
Milan Zamazal
--
And why?
next prev parent reply other threads:[~2001-06-17 12:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-27 11:32 Peter Novodvorsky
2001-05-28 2:43 ` Yngve Svendsen
2001-05-28 4:34 ` Peter Novodvorsky
2001-06-04 21:53 ` Margaret BRIERTON
2001-06-05 1:35 ` GNATS discussion group Yngve Svendsen
2001-06-05 19:56 ` Margaret BRIERTON
2001-06-06 4:54 ` Yngve Svendsen
2001-06-07 17:04 ` Margaret BRIERTON
2001-06-07 18:15 ` Database Margaret BRIERTON
2001-05-28 14:37 ` modular database backends Milan Zamazal
2001-05-29 12:43 ` Peter Novodvorsky
2001-06-11 11:53 ` Milan Zamazal
2001-06-13 10:31 ` Peter Novodvorsky
2001-06-17 12:26 ` Milan Zamazal [this message]
2001-06-11 11:53 ` access control (was Re: modular database backends) Milan Zamazal
2001-06-13 5:20 ` access control Hans-Albert Schneider
2001-06-17 12:26 ` Milan Zamazal
2001-06-13 10:44 ` access control (was Re: modular database backends) Peter Novodvorsky
2001-05-27 11:35 modular database backends Peter Novodvorsky
2001-05-29 0:11 Dirk Bergstrom
2001-05-29 0:22 ` Bob Kaehms
2001-05-29 1:16 ` Peter Novodvorsky
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8766dvxqk9.fsf@blackbird.zamazal.org \
--to=pdm@zamazal.org \
--cc=gnats-devel@sources.redhat.com \
--cc=nidd@altlinux.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).