db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: [Derby-655] : getImportedKeys returns duplicate rows in some cases
Date Wed, 24 May 2006 20:14:45 GMT
Thanks for taking the time to go through the loooong mail. My responses
inline.
Mamta


On 5/24/06, Daniel John Debrunner <djd@apache.org> wrote:
>
> 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'?


Sorry, I meant to say SYSCONSTRAINTS instead of the first SYSCONGLOMERATES.

> 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?


Yes, CONGLOMERATEID are no longer unique within SYSCONGLOMERATES and hence
the reference manual is not correct. I noticed this during my research
but wanted to thrash out my findings with the community before opening a
jira entry for 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.


The duplicate rows do have the same CONGLOMERATENUMBER which corresponds to
the physical conglomerate. But the CONGLOMERATEID which could be thought of
as logical conglomerate is not unique in SYSCONGLOMERATES. If we change the
CONGLOMERATEID to be a unique key in SYSCONGLOMERATES by changing the code
in CreateIndexConstantAction somehow, then we will not have to change the
metadata query in anyways and the reference manual will not have to change
for the release in which the fix will go. If we decide not to backport the
fix in older Derby releases, then we should fix the reference manual for
those releases.

Thanks,
Mamta

Thanks,
> Dan.
>
>
>
>
>
>
>

Mime
View raw message