db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael J. Segel" <mse...@segel.com>
Subject Re: Ability to create a unique index on the same column, doc bug or "bug" bug?
Date Thu, 25 Aug 2005 13:22:09 GMT
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" <msegel@segel.com> 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

Mime
View raw message