On Wednesday 24 August 2005 21:50, Jean T. Anderson wrote: *WARNING* This post may require the readers donning flame retardant clothing. ;-)
> Michael J. Segel wrote: > > On Wednesday 24 August 2005 18:33, Susan Cline wrote: > >>I just logged DERBY-539 as a documentation enhancement request. I think > >>if the documentation explains more clearly the behavior of the product it > >>will help our users when they observe something they might not > >> intuitively understand when first using the product. > >> > >>Susan > > Thanks for taking the time to log the improvement, Susan! > > Let's say I'm a developer deploying an embedded database on a machine > with tight resources. I have a table with a million rows in it and I > created an index on a column in that table. I would be grateful to know > up front that if I create a primary or foreign key on that column, I can > go ahead and drop that index and save some space. > Maybe thats the crux of it. Not many developers actually know or understand what or how a database should work. I wonder what is actually being taught these days in software engineering classes. (Anyone still using Date's book(s)?) If you re-read what you just said, you'll see that you're suggesting that you obfuscate reference texts with "insight" which should be basic understanding of how a database actually works. For those who are not Software Engineers, there is a principle called KISS. (Keep It Simple, Stupid) That is to say, don't make things overly complex. The goal here should be to keep Cloudscape/Derby as a minimalist Java Relational Database. Clearly we will want to add additional functionality, however we will want to do so in such a way that we keep the code clean. With respect to the constraint issue... Just because you don't understand what you are seeing, doesn't mean that its a bug. As I have said earlier, you have to understand what a constraint is, and how it is being applied when you create a UNIQUE INDEX and a PRIMARY INDEX. With respect to Indexes, you have to consider the order of precedence of different types of indexes, as well as the concept that you can have multiple indexes on a given table and that the Index is actually a separate object from the table, given that there is a weak relationship to a given table object. Sorry for the lecture, but when you start designing a system to save people from themselves, you create bloatware. Something I would hope to avoid with Cloudscape.... > >>"Michael J. Segel" <[EMAIL PROTECTED]> wrote: > >>On Tuesday 23 August 2005 13:20, Susan Cline wrote: > > > > Sigh. > > > > How is this behavior any different from any other database? > > > > I think my frustration is that Derby/Cloudscape is acting as expected. > > So we can clarify the documentation and save some users some confusion. > Sigh. You're actually making the documentation worse. I could understand if you're going to write a text book, where commentary may make sense, but as part of a reference book, you're adding something that clouds the issue. > > Did you try your sample tests against DB2? Informix? Sybase? > > Oracle?(ick!) > > What does that matter? Apache Derby isn't any of those databases. And > that is really, really, really sweet. > Well, thats gets to the heart of it. Susan saw some behavior within Cloudscape/Derby that she didn't understand. Tested it out and thought it was a bug. I asked if she tried to test this against other "professional/commercial grade" databases to see if they too would show the same response. The test would be to see if they did. If so, then hopefully Susan, or someone else who thinks that this is a bug, would find out if Cloudscape/Derby is acting in a different manner from other databases. If it is not, then clearly it is not a bug, but accepted behavior, and then ask why and then try to understand why. I offered a simple example to explain the behavior of constraints. (Create a table where a column allows NULL values, enter data with NULLS, and then ALTER the table to not allow NULLS in that column....) This example should show you that if you add a constraint, it will not effect data that already exists in the table. Yes, I do agree that Cloudscape is not DB2 and is not IDS... Cloudscape has a niche that it should do well. However, I do think that it is important that we keep Cloudscape clean, simple and as compact as possible. > It never hurts to improve the docs, especially when somebody provides > the suggested new content as Susan did with DERBY-539. > > -jean Again my point is that in this specific case, you're obfuscating the docs. I do see the need for some clarification. But not in the docs... ;-) -- Michael Segel Principal MSCC (312) 952-8175
