Re: No exceptions?
Date: Fri, 30 Jun 2006 02:57:17 GMT
Bob Badour wrote:
> The extend operation creates a new relation by adding an attribute to an
> existing one. Strictly speaking, whether the candidate key would be
> preserved depends on the operation used to derive the extended
> attributes. Ungrouping a relation valued attribute, for instance, would
> affect the key. However, most familiar extend operations would not.
Thanks for explanation and Okay, I think I see your point even though I was talking about relation definitions (something I didn't try to define in previous posts), not relations. I haven't been thinking about extend because again for my peculiar reasons, I want to avoid it too! (not convinced that it is essential.) Maybe one day I'll have enough of this approach together to explain why, but not now as I have my original question along with other unmentioned ones still to answer and I think I would get flamed if I put it all out there at once, probably would seem crazy to most people.
>>> Identifying the error condition is easy. The problem of >>> identification only arises after you replace the error with DEE or DUM. >>> ... >> >> It seems (as usual) that I haven't explained myself well enough. While >> at the UI, I think most people would consider a spelling error an >> error, I would like, at a very low internal level, to ignore typo's of >> that sort, evaluate it as written, and give a result that is logically >> consistent (assuming that is logically possible). I want to postpone >> what error decisions are shown at the UI level.
> Postponing seems counterproductive on a number of levels. From a user's
> perspective, getting a timely and somewhat detailed error message is
> much better than someday getting a highly detailed error message that
> includes details of something the user never asked for or wanted.
I have no problem with that, the issue for me is packaging and separation if I may put it loosely. Just coincidence I suppose, that you mention levels. If I'm making a part, I've learned that it doesn't please me unless I ruthlessly eliminate everything that isn't essential, eg., if it's join code, that includes eliminating any assumption that some outside layer has validated existence of this or that. Further, it avoids depending on just how such an error may be handled, in fact in different circumstances, different error treatments can make sense and AFAIAC those may demand a different language than a basic A-algebra. (I have some experience expunging the nonsense that grows from highly detailed error messages and I would agree if you said doing that is a mug's game.)
p Received on Fri Jun 30 2006 - 04:57:17 CEST