On Fri, Dec 22, 2006 at 09:41:17PM -0800, Stephen Lau wrote:
> terminating period?
"sunweb.central.sun.com." will tell the resolver (at least in DNS land) not
to try to append "domain" or "search" affixes as defined in resolv.conf and
try the lookups again for each of the defined nameservers.
> could you go into more detail about this 'pipe-table snafu'?
The "pipe" table is the table in the bugtraq schema that contains the state
change information -- agent and date -- for things like submitted by/when,
accepted by/when, etc (I guess the name means that it's the pipeline of
action for the bug). The schema for the table is here (sorry, non-Sun
folks):
http://hestia.sfbay/BugTraq2/schema/PIPE.html
The pipe table seems to be updated separately from the rest of the
database, as a database procedure that runs periodically. There have been
a handful of problems over the past year or so that have prevented the
procedure from running properly, or at all, and so the data in the pipe
table has lagged severely behind -- newly created bugs simply wouldn't be
there.
Thus, when you do a join against the pipe table using, say, cr_number as
the joining element, and cr_number isn't in the pipe table, then you get
empty results. Which is a bit silly if the bug is known to exist, and all
you cared about was bugid and synopsis.
Monaco hides all the table joins from you (which is its point, as it's the
joins that were killing the old system where everyone had raw SQL access),
but it also means that lots of people unwittingly do joins where they don't
necessarily need to. Like my code in wx.
I don't know if it's worth being clever about the pipe table in particular
and only doing a join with it -- or a query with an implicit join with it
-- only when you know you're going to need data from it, or what. And
there haven't been problems for a couple months now. But you/we should be
aware that the problems do exist.
Now, hopefully that all was correct and actually made sense to someone who
knows SQL more than I do, but it is correct to the best of my knowledge.
Danek
_______________________________________________
tools-discuss mailing list
[email protected]
