db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [Derby-655] : getImportedKeys returns duplicate rows in some cases
Date Wed, 24 May 2006 19:26:41 GMT
Mamta Satoor wrote:

[snip of first ten paragraphs]

This is very useful, but I have two quick clarifying questions on the
11th paragragh.

> In order to improve Derby's performance in conglomerate maintenance
> area, in
> Derby 10.0, few changes were made in
> org.apache.derby.impl.sql.execute.CreateIndexConstantAction.executeConstantAction,
> 
> so that if a new (backing)index was detected to be a duplicate of an
> existing index, then rather than creating a new conglomerate for it, the
> new
> index would share the conglomerate that was already created for the
> existing
> duplicate index.

Q1) For this next sentence, should the first 'SYSCONGLOMERATES' be
replaced with 'SYSCONSTRAINTS'?

> So, an entry will be made into SYSCONGLOMERATES for the
> new constraint and an entry will be made into SYSCONGLOMERATES for the new
> constraint but the CONGLOMERATEID of the new constraint will be same as the
> CONGLOMERATEID of the existing duplicate index.

Q2) Does this mean that the CONGLOMERATEID is no longer unique within
SYSCONGLOMERATES as described in the reference manual?

It seems that there is now a separation of congomerates into logical
congomerates (rows in SYSCONGLOMERATES) and physical conglomerates
(files on disk). But what you describe has the CONGLOMERATEID being the
physical identifier when it seems it should be a unique identifier for
the logical conglomerate. I would have thought the CONGLOMERATENUMBER
would be the physical identifier, thus in the situation you describe I
would expect two rows in SYSCONGLOMERATES with the same
CONGLOMERATENUMBER but unique CONGLOMERATEIDs.

Thanks,
Dan.







Mime
View raw message