[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dtp-pmc] 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 -----
| rcernich@xxxxxxxxxx
07/17/2006 11:07 AM
|
|
To
| rcernich@xxxxxxxxxx
|
|
cc
| 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
|
|
Subject
| 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
urging.
Rob
Rob Cernich
II/SYBASE
To
07/17/2006 12:05
Der Ping Chou <dpchou@xxxxxxxxxx>
PM
cc
avainch@xxxxxxxxxx,
Brian Payton
<bpayton@xxxxxxxxxx>,
brian.fitzpatrick@xxxxxxxxxx,
Hemant S
Kolwalkar
<hskolwal@xxxxxxxxxx>,
Hung.Hsi@xxxxxxxxxx,
Hong-Lee Yu
<hyu@xxxxxxxxxx>,
jograham@xxxxxxxxxx,
lchan@xxxxxxxxxxx,
Lawrence E
Dunnell
<ledunnel@xxxxxxxxxx>, Loic
R Julien
<lj@xxxxxxxxxx>, Sheila
Sholars
<sholars@xxxxxxxxxx>
Subject
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
discussion.
To bring migration into this discussion, Hemant's problems can be solved
by
implementing this through a customized model utilizing one of the suggested
strategies.
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:
old:
database.getSchema()
schema.setDatabase(database)
new:
((NonCatalogDatabase)database).getSchema()
schema.setCatalog((NonCatalogDatabase)database) or
((NonCatalogSchema)schema).setDatabase(database)
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).
Regards,
Rob
Der Ping Chou
<dpchou@xxxxxxxxx
m>
To
rcernich@xxxxxxxxxx
07/17/2006 11:37
cc
AM
avainch@xxxxxxxxxx,
Brian Payton
<bpayton@xxxxxxxxxx>,
brian.fitzpatrick@xxxxxxxxxx,
Hemant S
Kolwalkar
<hskolwal@xxxxxxxxxx>,
Hong-Lee Yu
<hyu@xxxxxxxxxx>,
Hung.Hsi@xxxxxxxxxx,
jograham@xxxxxxxxxx,
Lawrence E
Dunnell
<ledunnel@xxxxxxxxxx>,
lchan@xxxxxxxxxxx,
Loic R Julien
<lj@xxxxxxxxxx>,
Sheila Sholars
<sholars@xxxxxxxxxx>
Subject
Re: about
the DTP model change
proposal
for Catalog - please read
Rob,
Thank you for the input. See my comment in blue pen or quote.
Der-Ping
rcernich@syb
ase.com
To
07/17/2006 Hemant S Kolwalkar/Redmond/IBM@IBMUS,
09:43 AM jograham@xxxxxxxxxx
cc
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
Teresa/IBM@IBMUS
Subject
Re: about
the DTP model change proposal for Catalog -
please
read
Hemant,
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).
Regards,
Rob
Hemant S
Kolwalkar
<hskolwal@xxxxxx.
To
com>
Der Ping Chou <dpchou@xxxxxxxxxx>,
Sheila Sholars
07/16/2006 05:15
<sholars@xxxxxxxxxx>,
PM
avainch@xxxxxxxxxx,
Brian Payton
<bpayton@xxxxxxxxxx>,
rcernich@xxxxxxxxxx,
brian.fitzpatrick@xxxxxxxxxx,
Hung.Hsi@xxxxxxxxxx,
lchan@xxxxxxxxxxx
cc
Hong-Lee
Yu <hyu@xxxxxxxxxx>, Loic
R Julien
<lj@xxxxxxxxxx>, Lawrence
E Dunnell
<ledunnel@xxxxxxxxxx>
Subject
about the
DTP model change proposal
for Catalog
- please read
Hi,
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
base.
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,
Attachment:
pic07075.jpg
Description: JPEG image
Attachment:
pic08184.jpg
Description: JPEG image
Attachment:
pic27606.jpg
Description: JPEG image
