Re: [dtp-dev] Fine-grained refresh control on ICatalogObject

[Lawrence E Dunnell <ledunnel@xxxxxxxxxx>]

Here is the response from the engineer:

What happens if the PK column or table is removed?
 It seems like the
references will still exist.  I could be wrong, but it looks like
the code
doesn't do a very good job cleaning up these dangling references (this
includes the refactored, reusable catalog loading code).


"We don't remove the reference instead
we create a place holder for the dangling references. The reason is 
that the target(PK) May be filter out at
that time. Later on if user change the filter, and the target(PK) get 
loaded, the reference will be resolved
automatically."



Also, since refresh() is invoked on the child references, won't this cause
the columns and PK's to be reloaded anyway?  I guess that's the thing
I
find most confusing.  Although, I guess if those loaders are doing
the same
thing, the instances will be reused if they remain in existence, even if
their underlying meta-data changes (e.g. the PK's column).  If that's
the
case, is there also a need to update the elements referencing the PK?
(Note, I'm just using PK as an example, I assume this generally
applicable.)


"It depends on which level the refresh
apply to. If it refresh() on FK only, event it invoke on the child 
references, it won't trigger PK to be reloaded
because PK already loaded. If it refresh on Table level
all the children under this table (column,
constraint...) will be re-load." 



Larry Dunnell
RAD Data Tools, DB2 Tooling,  Eclipse WTP Project and Eclipse DTP
Project 
IBM DB2 Information Management Software

rcernich@xxxxxxxxxx
Sent by: dtp-dev-bounces@xxxxxxxxxxx

11/07/2006 10:24 AM

Please respond to
DTP development mailing list <dtp-dev@xxxxxxxxxxx>

To	DTP development mailing list <dtp-dev@xxxxxxxxxxx>
cc
Subject	Re: [dtp-dev] Fine-grained refresh control on ICatalogObject

Thanks Larry,

I have a couple of follow ups.

> Here is the explanation for the object re-use I got from our catalog
> loading expert:
>
> "It is used to keep the same reference when the target (like
PK
> table) is re-loaded.   This is needed when the table references
are
> cross-schema or the target is filtered out at that time of the refresh."

What happens if the PK column or table is removed?  It seems like
the
references will still exist.  I could be wrong, but it looks like
the code
doesn't do a very good job cleaning up these dangling references (this
includes the refactored, reusable catalog loading code).

Also, since refresh() is invoked on the child references, won't this cause
the columns and PK's to be reloaded anyway?  I guess that's the thing
I
find most confusing.  Although, I guess if those loaders are doing
the same
thing, the instances will be reused if they remain in existence, even if
their underlying meta-data changes (e.g. the PK's column).  If that's
the
case, is there also a need to update the elements referencing the PK?
(Note, I'm just using PK as an example, I assume this generally
applicable.)

I'd like to understand this better so I can improve the reusable catalog
loaders.

Thanks again for the explanation.
Rob

_______________________________________________
dtp-dev mailing list
dtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dtp-dev