[02:33:16] ** vlado__ has joined us
[04:03:35] [connected at Sat Nov  8 04:03:35 2003]
[04:03:35] <> *** Looking up your hostname...
[04:03:35] <> *** Checking ident
[04:03:35] <> *** Found your hostname
[04:04:07] <> *** No identd (auth) response
[04:04:07] <> *** Your host is tolkien.freenode.net[core1-gige-ds3.pfn.citynetwireless.net/6667], running version dancer-ircd-1.0.32
[04:04:07] [I have joined #peak]
[04:04:07] ** tolkien.freenode.net set the topic to PEAK http://peak.telecommunity.com || WikiPages at http://peak.telecommunity.com/DevCenter || IRC-Logs: http://peak.telecommunity.com/irc-logs/
[04:06:34] ** SteveA|home has joined us
[04:20:07] ** vlado has joined us
[04:39:06] * vlado is away, somewhere far beyond... (l!on)(p!off) [cRk/bx]
[08:43:20] ** vlado___ has joined us
[09:05:57] ** pje has joined us
[09:06:12] * pje waves
[09:23:08] ** pje has left us
[16:22:07] ** SteveA|home has joined us
[16:32:34] ** SteveA|home has joined us
[17:25:03] ** pje has joined us
[17:30:08] * pje is thinking about conceptual->physical schema mappings, and query transforms
[17:32:20] <pje> It seems that features and types can be expressed in terms of pairs of projections over a relvar.
[17:32:47] <pje> And all paths through a conceptual query are just chains of these projection/relvar "links"
[17:33:34] <pje> IN, EXISTS, MAYBE, etc. are all just "coloring" over edges that cross from one relvar to another.
[17:34:02] <pje> It should be really easy to define the O->R mapping structures.
[17:34:19] <pje> It's the query processing that's tricky.
[17:34:43] <pje> Well, not even that.  It's handling OR, EXISTS, MAYBE, and IN queries that are tricky.
[17:35:07] <pje> Heck, it's not even EXISTS and IN, those are actually pretty straightforward too.
[17:36:03] <pje> It's the various branches of an OR condition, when different branches diverge in join paths.
[17:36:44] <pje> They have to be treated as either subqueries, or as outer joins, depending on whether they contain any retrieved values.
[17:37:36] <pje> But, those portions of the branches that are present in the root, or are common to all branches, can be "promoted" into the higher level query.
[17:38:16] <pje> So, if I say foo.bar = baz or foo.spam = widget, and both .bar and .spam are in the same table, that table can be part of the parent query.
[17:38:35] <pje> But, if they are in different tables, then both tables have to be outer-joined from the parent query.
[17:40:09] <pje> It seems there ought to be a way to do this as a side-effect of algebraic simplification of the OR() node.
[17:40:34] <pje> That is (a&b)|(a&c) == a & (b|c).
[17:41:29] <pje> But I can't quite visualize how to do that with the table structures, since they're graphs.
[17:43:09] * pje sighs
[17:43:47] <pje> Maybe I should implement the parts I know how to do, first, so I can better visualize what's left.
[18:07:42] ** lex has joined us