On 3/13/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
>
>
> On Mar 13, 2006, at 8:23 PM, Cris Daniluk wrote:
>
> > Andrus - This is a bit of a complicated issue. I think it is
> > critical that we load both the source and target relationships for
> > a table on reverse engineer. The current behavior only loads
> > exported FKs for a table, relying on a comprehensive reverse
> > engineer to pick up the rest. We could handle this by calling
> > getImportedKeys on every table as well, and using some clever merge
> > support to avoid double-loading relationships, but I think that's a
> > biiig change.
> >
> > It seems like the least invasive option is to add a secondary pass
> > to load target relationships for tables that were not skipped, by
> > scanning relationships in tables that were skipped. This could be
> > as simple as just tracking DbEntities that were skipped in a set
> > and taking a pass through the relationships for matches to non-
> > skipped entities. Thoughts?
>
> I see. So the problem only happens when merging into an existing
> DataMap. Then the last option makes sense to me.
>
> I guess I never came across this issue myself, as the current merging
> algorithm is not that sophisticated so I usually prefer to maintain
> my schema by hand after the first reverse engineering run.
>
> Andrus
>
> Same here... I'd only noticed in PG because I tend to develop a lot of
small projects there (i.e. the data model changes frequently because I don't
take the time to plan it all out first :) )... its convenient to spit out
some SQL to create FKs and then import them into the modeler when you're
rapidly changing a data model.. at the same time I don't trust the modeler
enough to not skip entities that haven't changed.
Cris
This archive was generated by hypermail 2.0.0 : Mon Mar 13 2006 - 14:29:16 EST