Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Fw: [dtp-dev] Fw: about the DTP model change proposal for Catalog - please read

This is a proposal related to SQL Model changes to accommodate catalog object defined on SQL/99 spec. I would like to also cycle this on WTP community for RDB adopter.


Der-Ping Chou
Information Management Tooling
Development Manager - Data Tools
Seattle IBM Office
tel : 1-206-587-5946 (T/L: 277-5946)

----- Forwarded by Der Ping Chou/Redmond/IBM on 07/18/2006 01:57 PM -----
Der Ping Chou/Redmond/IBM@IBMUS
Sent by: dtp-dev-bounces@xxxxxxxxxxx

07/17/2006 01:06 PM

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

[dtp-dev] Fw: about the DTP model change proposal for Catalog -        please read

Forward to DTP-DEV.

Der-Ping Chou

----- Forwarded by Der Ping Chou/Redmond/IBM on 07/17/2006 01:05 PM -----

07/17/2006 11:07 AM

avainch@xxxxxxxxxx, Brian Payton/Santa Teresa/IBM@IBMUS, brian.fitzpatrick@xxxxxxxxxx, Der Ping Chou/Redmond/IBM@IBMUS, Hemant S Kolwalkar/Redmond/IBM@IBMUS, Hung.Hsi@xxxxxxxxxx, Hong-Lee Yu/Redmond/IBM@IBMUS, jograham@xxxxxxxxxx, lchan@xxxxxxxxxxx, Lawrence E Dunnell/Redmond/IBM@IBMUS, Loic R Julien/Redmond/IBM@IBMUS, Sheila Sholars/Santa Teresa/IBM@IBMUS
Re: about the DTP model change proposal for Catalog - please read

Please feel free to post any response to the dtp-dev list, per John's


           Rob Cernich                                                  
           07/17/2006 12:05          Der Ping Chou <dpchou@xxxxxxxxxx>  
           PM                                                         cc
                                     avainch@xxxxxxxxxx, Brian Payton    
                                     Hemant S Kolwalkar                  
                                     Hung.Hsi@xxxxxxxxxx, Hong-Lee Yu    
                                     lchan@xxxxxxxxxxx, Lawrence E      
                                     Dunnell <ledunnel@xxxxxxxxxx>, Loic
                                     R Julien <lj@xxxxxxxxxx>, Sheila    
                                     Sholars <sholars@xxxxxxxxxx>        
                                     Re: about the DTP model change      
                                     proposal for Catalog - please read  
                                     (Document link: Rob Cernich II)    

Hi Der Ping,

I appreciate you comments.

However, I do believe that Hemant's proposal, because it deviates from the
recommendations of the SQL specification, does pollute the model.  All of
these concepts can be accommodated through a customized model.  This was
the purpose for detailing migration strategies within a separate

To bring migration into this discussion, Hemant's problems can be solved by
implementing this through a customized model utilizing one of the suggested

I was able to very easily migrate the Derby support within DTP by extending
NonCatalogDatabase instead of Database (as discussed).  I did need to tweak
the schema catalog object, since g/setDatabase() were no longer available.
However, this could have been more easily accomplished by extending a
NonCatalogSchema object (e.g. setDatabase() would invoke
setCatalog((NonCatalogDatabse)database)).  Using these base types would
make your migration much simpler.

As Hemant noted, a number of compilation errors are produced after
migrating the model.  However, what he didn't say or possibly didn't
realize, was that most of these can be fixed by casting the base object
down to the customized type.  For example:
    schema.setCatalog((NonCatalogDatabase)database) or

At this point, it is really a matter of investigating and fixing these
errors.  As I pointed out earlier, this does not take a lot of time,
especially if you are using base types which implement the more complicated
logic (i.e. delegating to the Catalog objects).


           Der Ping Chou                                                
           m>                                                         To
           07/17/2006 11:37                                           cc
           AM                        avainch@xxxxxxxxxx, Brian Payton    
                                     Hemant S Kolwalkar                  
                                     <hskolwal@xxxxxxxxxx>, Hong-Lee Yu  
                                     jograham@xxxxxxxxxx, Lawrence E    
                                     Dunnell <ledunnel@xxxxxxxxxx>,      
                                     lchan@xxxxxxxxxxx, Loic R Julien    
                                     <lj@xxxxxxxxxx>, Sheila Sholars    
                                     Re: about the DTP model change      
                                     proposal for Catalog - please read  


Thank you for the input. See my comment in blue pen or quote.


07/17/2006        Hemant S Kolwalkar/Redmond/IBM@IBMUS,                  
09:43 AM          jograham@xxxxxxxxxx                                    
                 avainch@xxxxxxxxxx, Brian Payton/Santa                  
                 Teresa/IBM@IBMUS, brian.fitzpatrick@xxxxxxxxxx, Der    
                 Ping Chou/Redmond/IBM@IBMUS, Hung.Hsi@xxxxxxxxxx,      
                 Hong-Lee Yu/Redmond/IBM@IBMUS, lchan@xxxxxxxxxxx,      
                 Lawrence E Dunnell/Redmond/IBM@IBMUS, Loic R            
                 Julien/Redmond/IBM@IBMUS, Sheila Sholars/Santa          
                 Re: about the DTP model change proposal for Catalog -  
                 please read                                            


A couple of things:

1.  It was agreed that the model should be as clean as possible and that
introducing concepts purely for migration purposes was not a good thing.
[DPC - The proposal that Hemant brought up to the discussion was one of the
proposal considered, it is as clean as what we proposed to DTP.
However, it include an ease migration path for WTP adoption. The area of impact is beyond
catalog loading, it also involve in relationship exploring, enumeration,
navigation, logical containment and more.]

2.  DTP 0.9 does not allow the user to save models to the workspace.
Furthermore, I don't agree that this is enough of an issue to warrant
polluting the model, as the user can always regenerate the persisted
information by connecting to the database.  If this is not acceptable, a
migration script or customized resource loader can be used to solve the
problem (I believe these were also discussed).[DPC - I understand this is
how DTP consume the model, but we should also consider how the migration is
impacting WTP.]

3.  After migrating DTP to use the updated model, I have to question the
amount of effort you say is required to migrate existing models.  As I
stated previously, it took me less than two days to migrate DTP to use the
new model.  This included migrating the Derby and generic JDBC profiles and
catalog loaders as well as the navigator code (injecting Catalog into the
hierarchy).  (If you would like, I could dig up the patch file that I sent
around prior to discussion, which you could use that as an example of the
migration effort.  One thing you will need to do is create a class similar
to NonCatalogDatabase within your model, as the changes I sent out had this
class implemented within the base model.)[DPC - I agree with your estimate
on the extent of impacting DTP.]

4.  Changing the base database class from Database to AbstractDatabse
causes API changes that ripple through catalog loaders, requiring a change
to every ICatalogObject and code that uses
ICatalogObject.getCatalogDatabase() (because the return value for
getCatalogDatabase() would need to be changed from Database to
AbstractDatabase).  These changes are far more impacting than those
required under the accepted proposal (I tried both ways).

That said, I don't think abandoning the current, accepted and agreed upon
proposal is warranted (or even a good idea).


          Hemant S
          <hskolwal@xxxxxx.                                          To
          com>                      Der Ping Chou <dpchou@xxxxxxxxxx>,
                                    Sheila Sholars
          07/16/2006 05:15          <sholars@xxxxxxxxxx>,
          PM                        avainch@xxxxxxxxxx, Brian Payton
                                    Hong-Lee Yu <hyu@xxxxxxxxxx>, Loic
                                    R Julien <lj@xxxxxxxxxx>, Lawrence
                                    E Dunnell <ledunnel@xxxxxxxxxx>
                                    about the DTP model change proposal
                                    for Catalog - please read


As we all know, in our last meeting to discuss changes to the SQLModel
inorder to support concept of Catalog, we had agreed on the following
proposal :

(Embedded image moved to file: pic27606.jpg)

Note: model resource = instances of model persisted to a resource file.

One of the concerns expressed by me then was of model resource/code
migration for existing WTP users. I had submitted a proposal which would
mitigate risks associated with the migration. However at that time, it was
pointed out that we would need a model resource/code migration anyway
because of the namespace change from WTP to DTP model.  As such, the
conclusion was since we would anyway be putting in the effort for model
resource migration for the namespace change, we could adopt the above
change in the same stride.

Subsequently our team did some prototyping and have realized that the
effort involved with the namespace change is trivial as far as model
resource migration is concerned. What is more important is we preserve the
names of existing model classes and the relationships between them. Because
any change to them would trigger the need for model resource migration.

Based on the above proposal, I modified the WTP SQL Model in my local
workspace. I ran into a huge amount of compile errors with the WTP code
Also, at runtime, while opening existing model resources, I ran into
problems as the Database - Schema relationship does not exist anymore.

My proposal is as follows. The AbstractDatabase class would carry the two
attributes for Vendor and Version, instead of the Database class. In my
opinion, this approach allows both existing and future models to co-exist.
(Embedded image moved to file: pic08184.jpg)
Based on my proposal, I modified the WTP SQL Model in my local workspace.
The changes required to the WTP code as a result of the model changes were
almost none. Also, at runtime, I could open existing model resources
without any problems.

Rob had another proposal as below. Based on his proposal, I modified the
WTP SQL Model in my local workspace. I had to hand-code get/setDatabase()
methods in Schema to resolve compile time errors in our WTP code.  Also, at
runtime, while opening existing model resources, I ran into problems as the
Database - Schema relationship does not exist anymore.

(Embedded image moved to file: pic07075.jpg)

Considering these facts, I would strongly suggest abandoning our current
proposal and adopting the proposal I had suggested. It will payoff in terms
of the easing considerably the migration of existing WTP users to the DTP
code base.

Comments welcome.

Thanks for your time,

dtp-dev mailing list

Attachment: pic07075.jpg
Description: JPEG image

Attachment: pic08184.jpg
Description: JPEG image

Attachment: pic27606.jpg
Description: JPEG image

Back to the top