Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » DTP » Trouble with overrideLoader
Trouble with overrideLoader [message #41809] Fri, 22 February 2008 00:14 Go to next message
Enrico Schenk is currently offline Enrico SchenkFriend
Messages: 23
Registered: July 2009
Junior Member
Hello,

I am currently developing a bundle of plug-ins to provide Ingres support
for DTP.

At the moment I have two questions regarding to the catalog loading.

1. JDBC loader

To provide additional catalog information for DTP, I use the
"overrideLoader" extension point. This way I did not have to implement
the entire catalog structure. After all I'm a bit unsure if I use the
API as it is meant to be used. After testing the implementation of a
table loader (it just replaces the view and the table factory), I have
seen an unexpected result. The following steps were done in the data
source explorer.

1. Loading table A's columns
2. Loading table B's columns
3. Refreshing table A's columns

To my surprise I have seen the columns of table B as columns of table A
(the effect occurs only when using an override loader).

After having a closer look at the source code, I found out that

* There is always exactly one instance of a specific override loader
* The loader's instance is shared between all requesting objects (e.g.
tables)
* A loader has a catalog object that depends on the requesting object
(e.g. the JDBCTableColumnLoader expects the catalog object to be an
instance of Table)

When a object uses its cached loader, the loader is sometimes
initialized with the wrong catalog object (due to sharing). Are the
loaders meant to be used in a stateless way? If so, can you provide an
example?

2. ProcedureColumnLoader and TableColumnLoader

JDBCProcedure.createParameterLoader() and JDBCTable.createColumnLoader()
uses both the EClass of Column to find possible override loaders.
Because of casting the result to the according loader (in JDBCProcedure
and JDBCTable), I get some class cast exceptions when trying to retrieve
table columns or procedure columns.

Thanks in advance,

Enrico Schenk

Software Engineer
Ingres Germany GmbH - European Technology Center

PS: It's planned to contribute the plug-ins (including the source code)
to the eclipse foundation. Can you point me in the right direction for
the required steps?
Re: Trouble with overrideLoader [message #41848 is a reply to message #41809] Fri, 22 February 2008 15:36 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: brianf.sybase.com

Hi Enrico...

Sorry I didn't get back to your mailing list posting earlier, but glad you
reposted here.

That's definitely an odd behavior you found with (1). I know that there has
been some discussion of having multiple levels of override loaders with
priorities and such to allow for a hierarchy, so that may clear up this
issue in Ganymede.

Can you provide some example code perhaps using Derby or one of the other
profiles to reproduce this issue? I'd be happy to look at it. Obviously it
warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.

As for (2), yeah, I wondered about that when I wrote that code in the first
place. Because of the way those are structured, you'd have to actually
override the routine loader or the table loader and provide your own column
loader below them to avoid that problem. At this point I don't have a
better solution other than implementing the whole catalog loader down the
line.

As for contributing your Ingres code, we'd love to have that in the
Enablement project part of DTP. Please contact John Graham
(john.graham@sybase.com) and he can help point you in the right direction.

--Brian Fitzpatrick
Sybase, Inc.
Sr. Software Engineer
DataTools Connectivity Lead

"Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
news:fpl453$t64$1@build.eclipse.org...
> Hello,
>
> I am currently developing a bundle of plug-ins to provide Ingres support
> for DTP.
>
> At the moment I have two questions regarding to the catalog loading.
>
> 1. JDBC loader
>
> To provide additional catalog information for DTP, I use the
> "overrideLoader" extension point. This way I did not have to implement the
> entire catalog structure. After all I'm a bit unsure if I use the API as
> it is meant to be used. After testing the implementation of a table loader
> (it just replaces the view and the table factory), I have seen an
> unexpected result. The following steps were done in the data source
> explorer.
>
> 1. Loading table A's columns
> 2. Loading table B's columns
> 3. Refreshing table A's columns
>
> To my surprise I have seen the columns of table B as columns of table A
> (the effect occurs only when using an override loader).
>
> After having a closer look at the source code, I found out that
>
> * There is always exactly one instance of a specific override loader
> * The loader's instance is shared between all requesting objects (e.g.
> tables)
> * A loader has a catalog object that depends on the requesting object
> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
> instance of Table)
>
> When a object uses its cached loader, the loader is sometimes initialized
> with the wrong catalog object (due to sharing). Are the loaders meant to
> be used in a stateless way? If so, can you provide an example?
>
> 2. ProcedureColumnLoader and TableColumnLoader
>
> JDBCProcedure.createParameterLoader() and JDBCTable.createColumnLoader()
> uses both the EClass of Column to find possible override loaders. Because
> of casting the result to the according loader (in JDBCProcedure and
> JDBCTable), I get some class cast exceptions when trying to retrieve table
> columns or procedure columns.
>
> Thanks in advance,
>
> Enrico Schenk
>
> Software Engineer
> Ingres Germany GmbH - European Technology Center
>
> PS: It's planned to contribute the plug-ins (including the source code) to
> the eclipse foundation. Can you point me in the right direction for the
> required steps?
Re: Trouble with overrideLoader [message #41970 is a reply to message #41848] Mon, 25 February 2008 15:31 Go to previous messageGo to next message
Enrico Schenk is currently offline Enrico SchenkFriend
Messages: 23
Registered: July 2009
Junior Member
This is a multi-part message in MIME format.
--------------030801080508090304060203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello Brian,

thanks for your reply. I wasn't sure if the mailing list is alive so I
reposted the message here.

I've a JUnit test for the override loader problem (the source is
attached to this mail). It basically uses two different databases and
retrieves the schemas for both of them. Afterwards it refreshes one of
the databases and shows that this instance lists an additional schema
(which belongs to the other database).

To get the test running you should adjust the properties in
configuration.properties to fit your environment (location of the Derby
10.1 driver, ...). The class
org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
contains the test and should therefore run as "JUnit Plug-in Test".
Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
can have look at the setup code :).

Regarding the column loaders. I was afraid you said something like that.
Luckily I've already derived tables, views and procedures, so I can
easily add the column loaders.

Thank you,

Enrico Schenk

Software Engineer
Ingres Germany GmbH - European Technology Center

Brian Fitzpatrick wrote:
> Hi Enrico...
>
> Sorry I didn't get back to your mailing list posting earlier, but glad you
> reposted here.
>
> That's definitely an odd behavior you found with (1). I know that there has
> been some discussion of having multiple levels of override loaders with
> priorities and such to allow for a hierarchy, so that may clear up this
> issue in Ganymede.
>
> Can you provide some example code perhaps using Derby or one of the other
> profiles to reproduce this issue? I'd be happy to look at it. Obviously it
> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>
> As for (2), yeah, I wondered about that when I wrote that code in the first
> place. Because of the way those are structured, you'd have to actually
> override the routine loader or the table loader and provide your own column
> loader below them to avoid that problem. At this point I don't have a
> better solution other than implementing the whole catalog loader down the
> line.
>
> As for contributing your Ingres code, we'd love to have that in the
> Enablement project part of DTP. Please contact John Graham
> (john.graham@sybase.com) and he can help point you in the right direction.
>
> --Brian Fitzpatrick
> Sybase, Inc.
> Sr. Software Engineer
> DataTools Connectivity Lead
>
> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
> news:fpl453$t64$1@build.eclipse.org...
>> Hello,
>>
>> I am currently developing a bundle of plug-ins to provide Ingres support
>> for DTP.
>>
>> At the moment I have two questions regarding to the catalog loading.
>>
>> 1. JDBC loader
>>
>> To provide additional catalog information for DTP, I use the
>> "overrideLoader" extension point. This way I did not have to implement the
>> entire catalog structure. After all I'm a bit unsure if I use the API as
>> it is meant to be used. After testing the implementation of a table loader
>> (it just replaces the view and the table factory), I have seen an
>> unexpected result. The following steps were done in the data source
>> explorer.
>>
>> 1. Loading table A's columns
>> 2. Loading table B's columns
>> 3. Refreshing table A's columns
>>
>> To my surprise I have seen the columns of table B as columns of table A
>> (the effect occurs only when using an override loader).
>>
>> After having a closer look at the source code, I found out that
>>
>> * There is always exactly one instance of a specific override loader
>> * The loader's instance is shared between all requesting objects (e.g.
>> tables)
>> * A loader has a catalog object that depends on the requesting object
>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>> instance of Table)
>>
>> When a object uses its cached loader, the loader is sometimes initialized
>> with the wrong catalog object (due to sharing). Are the loaders meant to
>> be used in a stateless way? If so, can you provide an example?
>>
>> 2. ProcedureColumnLoader and TableColumnLoader
>>
>> JDBCProcedure.createParameterLoader() and JDBCTable.createColumnLoader()
>> uses both the EClass of Column to find possible override loaders. Because
>> of casting the result to the according loader (in JDBCProcedure and
>> JDBCTable), I get some class cast exceptions when trying to retrieve table
>> columns or procedure columns.
>>
>> Thanks in advance,
>>
>> Enrico Schenk
>>
>> Software Engineer
>> Ingres Germany GmbH - European Technology Center
>>
>> PS: It's planned to contribute the plug-ins (including the source code) to
>> the eclipse foundation. Can you point me in the right direction for the
>> required steps?
>
>


--------------030801080508090304060203
Content-Type: application/x-zip-compressed;
name="org.eclipse.datatools.connectivity.sqm.loader.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="org.eclipse.datatools.connectivity.sqm.loader.zip "

UEsDBBQAAAAIAJJFWTjVHJzSpQAAADMBAAA9AAAAb3JnLmVjbGlwc2UuZGF0 YXRvb2xzLmNv
bm5lY3Rpdml0eS5zcW0ubG9hZGVyLnRlc3QvLmNsYXNzcGF0aJ2PPQvCMBRF ZwX/Q8huqptD
axGpoEOVUmepyaONxpeYD9F/b1WKLjq4vXs5nMuL0+tJkQtYJzUmdMxGlABy LSTWCd2Wi+GE
ptNBP+aqcs5UvmlD750Avb2Ro0SRUGc5JY/ydUbfSa6xI7WtGXAljQN2EJ6p KiBv2nW2KrLd
fJ2Xs2WeFX/YjADGtQVm4RykBbFRoZbofql08Cb4zraX+ITj6PP7O1BLAwQU AAAACACSRVk4
aga4JfsAAADHAgAAOwAAAG9yZy5lY2xpcHNlLmRhdGF0b29scy5jb25uZWN0 aXZpdHkuc3Ft
LmxvYWRlci50ZXN0Ly5wcm9qZWN0vZLPTsQgEMbPmvgOm96F9eaB7SZq9qYx WX0AhLGygQFh
2ujbC9hqmmriwextvo/5+A1/xPbN2dUAMRmPm+aCrZsVoPLaYLdpHh9255fN tj07FSH6Ayi6
gaSiCZS7s3siUDpofewYKGtCAqYlSfLeJqY8Yk6YwdA7S6+OWS81REaQSPAa LDso7xwgtYJP
VXFHXKqCz9RTb6zeB1BFjfI6RyXq6vww1EFTHifmQg6yBiB+j5ATMnZ9YadR 87kh+ILyJ27Q
wG4lmud85KvjYvfqBZz8F+joTFeeedRHGLs/xQJ/b/vO4F1dLPTa9Ftg9jy4 yEx1IX79hflH
/ABQSwMECgAAAAAATntZOAAAAAAAAAAAAAAAADcAAABvcmcuZWNsaXBzZS5k YXRhdG9vbHMu
Y29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9iaW4vUEsDBBQAAAAIAJJF WTjSW2D7PwAA
AFAAAABDAAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xzLmNvbm5lY3Rpdml0eS5z cW0ubG9hZGVy
LnRlc3QvYnVpbGQucHJvcGVydGllcyvOLy1KTtXTU7BVKC5K1uflyi8tKSgt AQskZeYBBYCk
XmZeck5pSmoxUNDXNcRR19PPTV8nhpdLARXo8XIBAFBLAwQKAAAAAABKe1k4 AAAAAAAAAAAA
AAAAPAAAAG9yZy5lY2xpcHNlLmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3Ft LmxvYWRlci50
ZXN0L01FVEEtSU5GL1BLAwQUAAAACAA0WVk4GlQJRa0AAACEAQAARwAAAG9y Zy5lY2xpcHNl
LmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L01FVEEt SU5GL01BTklG
RVNULk1GjY4xDsIwDEX3nqIHIBEgpo7sRQgQe5qYyiiJaeIg9fYE2iIYKnWz /J6/f6083iCy
uEKISL4qN3Jd7JM3FkQ9wi/bTuSgHFTlJbPyaFMr0E/k3LuGLOrBoNBK0BYf EaRRrJjIRqnJ
e9CMT+Rexs5JS8pAkJzzppzfPrnRCbqEAcRA/4M1BZAheUYHq2Lpz/fVIntW cmTANirvYmdH
65488m72JIvDAAaZwqdE8QJQSwMECgAAAAAASntZOAAAAAAAAAAAAAAAADcA AABvcmcuZWNs
aXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9z cmMvUEsDBAoA
AAAAAEp7WTgAAAAAAAAAAAAAAAA7AAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xz LmNvbm5lY3Rp
dml0eS5zcW0ubG9hZGVyLnRlc3Qvc3JjL29yZy9QSwMECgAAAAAASntZOAAA AAAAAAAAAAAA
AEMAAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5s b2FkZXIudGVz
dC9zcmMvb3JnL2VjbGlwc2UvUEsDBAoAAAAAAEp7WTgAAAAAAAAAAAAAAABN AAAAb3JnLmVj
bGlwc2UuZGF0YXRvb2xzLmNvbm5lY3Rpdml0eS5zcW0ubG9hZGVyLnRlc3Qv c3JjL29yZy9l
Y2xpcHNlL2RhdGF0b29scy9QSwMECgAAAAAASntZOAAAAAAAAAAAAAAAAFoA AABvcmcuZWNs
aXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9z cmMvb3JnL2Vj
bGlwc2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9QSwMECgAAAAAASntZOAAA AAAAAAAAAAAA
AF4AAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5s b2FkZXIudGVz
dC9zcmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9zcW0v UEsDBAoAAAAA
AEp7WTgAAAAAAAAAAAAAAABlAAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xzLmNv bm5lY3Rpdml0
eS5zcW0ubG9hZGVyLnRlc3Qvc3JjL29yZy9lY2xpcHNlL2RhdGF0b29scy9j b25uZWN0aXZp
dHkvc3FtL2xvYWRlci9QSwMECgAAAAAASntZOAAAAAAAAAAAAAAAAGoAAABv cmcuZWNsaXBz
ZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMv b3JnL2VjbGlw
c2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9zcW0vbG9hZGVyL3Rlc3QvUEsD BBQAAAAIAEty
WTjTroUzCQEAABEDAAB5AAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xzLmNvbm5l Y3Rpdml0eS5z
cW0ubG9hZGVyLnRlc3Qvc3JjL29yZy9lY2xpcHNlL2RhdGF0b29scy9jb25u ZWN0aXZpdHkv
c3FtL2xvYWRlci90ZXN0L2Jhc2UucHJvcGVydGllc5WSz07DMAzG70i8Q5/A Wq9FObBmB1CH
Khji0kv+eCOoTSInK+rbk2Yb5+zoxJ/9+2w7OgGq0fiAoEUU0bkxgHLWoopm NnEBLf9jZ3ty
HikaDOzxwRWJg5ix/+Is0hnLNGRmpAAaj/aweGQlGpnSSS71poYTWiSjeC5z wMmPIqbOP4I6
EyLLeZCiMhgJ54BkxYTFji8G2lGEkNmFF+ob4dpYSwW7SaLWqC+MxXXTjxQB 31aYj+d93+3K
pLkLx6OxZl3iC2f89mSBr1jVjah65du2uo/LJ6O/jnTxgD7fO7bOockjadpm GDIFvxoMw7Bf
+PZJEabV3XE5EtbLSRZZvYG6XGO1I5YR/gBQSwMEFAAAAAgAEXlZOOgGBo5z AwAAfwsAAIAA
AABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2Fk ZXIudGVzdC9z
cmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9zcW0vbG9h ZGVyL3Rlc3Qv
Q2F0YWxvZ0xvYWRlclRlc3QuamF2YaVWTU/jMBA9F2n/g4U4pKi42nNVafvB ISso1ZY9Izd2
W7NJHGynpVrx33f8kTQmQCl72Cwez7wZz7xntyDJH7JmSMg1ZknKC8UwJZpo IVKFE5HnLNF8
y/Ueq6cMp4JQJrFmSg++nX0741khpEaPZEtwqXmK51IUTGrOVHP/E+gTvxA5 QKx4yq6fE1aY
9eAUmLiFc1K4j7klOTRFnhRKJd8yqfDU/h/nSpM8OS17CPE/RcR+DvsF018C aMTHWZF+CeOR
LhMc/5yOJ62hgMH0R6tjwJmgLF0SsKmnFKtkwzKCp7BtbMeCIaQqT7I6KqYs 13zFj7c2jC9c
6RVHfgPdLceLcpnyBCUpUQpNIDgV6xurk3uQCfprfDr9y0v4oks0kYyAfBDJ KQqpglZSZEhv
GFqDOUdEa8mXZeVMKFV217XXoWlhTQFhMLoHk2RPpUnPFeLrHOqnPcRXiPhw tON6c0jm0Dhk
SaE+ukfsmSutsLO774+CSJKhnGQsMHAaLIv6BrDmPnx9h7YCEiT2/K7gaAEn zNcWsof8gkOh
h1ukAdc1rex04BBReN41cNT3MOqaVdjX8T6eRpx20XCI8jJNPU6nqZEqjf0b 3NgOzUMFRK5I
wBnY6EYAVkwfKo7MARpVW45AwKth03DpcoY+USOHz/rRwYEgr+LDHA7iBT4v 71DS1mD+US8V
5DmPVkK+yUyMRivN5I5IICdxcEkt9jqsggEyuvlTS2mzBaIRCbemSqBILB8B wHNSAZV1KXNG
HbEbWLnQNZ7ldrUXkrtB2ZDeME7oDRisr7UZBjYylMqUWh/xU3qA8C0H9ceh LqqeHpjit93x
/EJvpNjBNfLua/haVHXTvLD88k1pHSoLJNaurIuO1uFE1O/7vND8xtzfpo2p xc49uCKsoMN3
t61ovz/ezwDDSrElZ39GylQiuStxiM7PB6jfv5jdza5mN4ur7xdNV5gLvAQe +l3nJbwAjADp
Sy18O8B3RVL7/oDDh7W77ngXf4c0SuwFM2kPohcW2WtWUevZDwISu/ehYgSv Hzrj0f5lVI9p
iL7Qf5u9arpPaXYBzeOawHFwnBrMXmvRkd8GeDq6H41Hi+uH2ej2+mH+627+ EE+DxD5TO6+t
07m23/263obJX8CtjaiRohcctLrZnX6rFpqfBfYNqoTYzmXLsnN7+QdQSwME FAAAAAgAEm5Z
OLArGZooAQAAZQIAAHwAAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVj dGl2aXR5LnNx
bS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nvbm5l Y3Rpdml0eS9z
cW0vbG9hZGVyL3Rlc3QvQ29uZmlndXJhdGlvbi5qYXZhlVFNawIxED0r+B+m IrhSjPS89FDt
3nSFFc+SxnGbGpM0mZUuxf/erLHYLfZQCOGRvHkfieViz0sE40qGQknrkW05 cTJGeSaM1ihI
HiXVzL8fmDJ8i44Rekp73V5XHqxxBG/8yFlFUrGF9F7qskBvKicw+xBoSRqd 3uB+k6aV3io8
69nqRUkBQnHvYWb0TpaV440AfPa6HevkkROCDwEDbSc1V7AiFxxhus6f59km f1pk8Aj9/xdq
Lq9+/RQmk0G+zMf5fDV+GDTpbvu3a0CRrZbrYpZtYqCQpU1gJVJEyY/Io7Rl 0KqejM7lT5ER
X+iS4NI9SEaUXA72WMehDrk6go5Dqpz+nY9dZ5uhtKGeQHASr5D89ZuAo7bo 8G4I941r2AOO
KjFzWF9QSwMEFAAAAAgASXdZOJkoA0WPAAAAMgEAAIIAAABvcmcuZWNsaXBz ZS5kYXRhdG9v
bHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlw c2UvZGF0YXRv
b2xzL2Nvbm5lY3Rpdml0eS9zcW0vbG9hZGVyL3Rlc3QvY29uZmlndXJhdGlv bi5wcm9wZXJ0
aWVzpY3BCsIwEETvgp/SYPAWyS3HQEFbvOSySRaaYqlstgX/3kREEAUPHmeY N69dkShFtDNE
pA4zi0iplGIEsimzNso5g6tz0Tdl4m+N3Akp9kI6d0m+9LWs8+2m/fIGDB4y nhMPpzDgBKI/
Wj1GH9SDVFXQ4XStmpLNE8jl+YM9BEJg1EwL/tTNC/9jfOHv0jtQSwMEFAAA AAgACXtZOKTx
WcZcBgAAYRkAAIEAAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2 aXR5LnNxbS5s
b2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nvbm5lY3Rp dml0eS9zcW0v
bG9hZGVyL3Rlc3QvT3ZlcnJpZGVMb2FkZXJUZXN0LmphdmHNWdtu2zgQfVaA /ANhFKjculR3
X9Mu6sReNItcurGDok8FLVE2U5lURSqOd9F/3+FFN0t27SYt9iW2xZnh8PDM 8FBJSfiFzCkS
2RzTMGGppDgiiighEolDwTkNFbtnao3l1yVOBIlohhWV6uT46PiILVORKSTB gYXoLudM4Tgj
S7oS2Rc8lJJmChPz8SdJJD05yGWa5bQ+zR25J5gJfH49fghpqpjgJ+1BnuZq ojJKlhuD8muC
z9yKWp56cPL3xbbAuWIJvmBm2a3nHzKRQrqMynq2e0BaZQMhYpbQjun3CHPe inOQu/O5JByY
kB3kqjkRioziTFFIA4wSMb+e3YHB9+IsRUSTGYFnGnoZLuiSYBfhh3xHMKyf /ZDzxHx0u9Jl
DItcLgW32z1u8kCbWhoPY7WJnx04pTGA1DUyLSopePHi+Ai9QPqBRGCO1ALK 8p5mGYvohak7
RB8U5RK2GaWCcYWNh3UTaEm+UOOkTIgsBytDzGQ9QGuRowW5h0GBSHSXS2VM 05K5iHETCLY3
ZvM8I5pNuDbuRxmDbCTwPkOaL4jwyASJHPAoEaFx62P0SeQmnFyIPIlsbjLP 6AA8iGq6MUiW
hlCwikbIZ1wqSiIkYpRLxucwjYlEHwB1/Vtw2tdPguOjNJ8l0ETCBPoFum5g pXG0eEUSOVrV
Rv7VmHspLAlmLZpRzDhJEPQOPc1oOB2eDifjzx/Pp++vb6efJ2fvx5dD9Bb1 CqahFVOwPoUs
e9Dzy0/W6HnvBAXBs6vrq1dXF5NXvz07bLZtUz3BPJefasGLMJ1RqqaGdAKN HlcftLQ43Wni
FvER1mCXsJcpINthDfYlKO3AJ9uGy2A2hCk3z9WbLgog6qriZkZlnijNQcI3 izCiqSEVVCFT
z3XhcJrZYBpxis13YKf3TgfXG2Jpei9YZE3iPGmy1e9rRnqeaS1vbKJ/INub DETeDHoXhWQW
RNbX4QUBJMwq4FAkAEYulCt3WIwNU9tu7ediAw1835VHvxswPKfKWUi/r3/5 r/vm047DQ5Nh
mRnEhC6iCFSyfeC7yQYV/axLTRn4FdVdz9BrcHEay0AvqzCDCo9+F4nb8BSZ PQKZXwSLVj9t
VNqIPBKQPfhiOr2d34XQ9hlVecYRKeyhWEz9cNBy2sz3m4JgC736OKMx1Nvi sXg5Gk0bq3sq
LnnfDHzv7Em+WdOARAolrBaZWElUijhb02a0amFmmQ5Ge+gBhNACZmvXSnVj 0TnGyVqbWZuR
GQI6GMPxckajCE7Lv0anZ8iO9QZwWphvIxpzvNOwq2dvrrn+6/dnmymrlahA Tq2AlLXMDWWc
VCxBGLWKyO15a7RkhzVw4Bt9tYE9aIVsJFa86KA6xURAUiRJKs1QiFbBpTZq C+ZiDUC6phzW
BX0OkoTwkNoyd+On6ysgut91cHfQx3PxccSkS6YkwpNMXSmUA2Z3wLa4XGdr werapcupJ692
1YJT0H15i3Rj1IrM5nxDpcizkA6lNfB7AcjfwInroNTlQf1iEcDFIrCXzUDL 2cDo9UqN9rqb
W1OoQCqcrtBG6W1amTutX6Rf7ElXhWyL12WLAZlhkvjNuXbb+z2Q1loAQIWe NWS4PlSMfvN7
bZWLbTxcOPc3seko5F2KbOsyd/jsXO53/PzeHhfNaIaLOJr7ptnpDjc6rcK2 SLHZwp4ul9ub
i0M3qS0gdJBDN6tDE++zXx1u+27ZFtd9kdqxa2XkAzduW0bazvP2zOtxO1iJ 4302cVub7ToP
i3a7/dWQPedKXViewm/d2VyMdB5Ng4NAMrIEUyciyuEyJy0ldlTU97bVndc7 Xw6QZEXWUkuz
unArpKmOUCGlj3kj27cJT3MgVfauUFS2tph64I8tiBOAhC4ph3MS0wca5gqk 5dnNeDgdI3eB
bojHrkP3GwqJChfIr79XRNQJFb1yNuegJiPzuoeL1UCrkBmZgXyKcvuqBvR1 AglF60rLWAjM
BNuaOYBQPNxxytfpVxNcP4uBlUL5qSTs6A5PwcMlg0vG/4CDo5vrD7+Ugebu tB/5Suh38a94
kbFxt+t68TEo3lrpK6VLWicKak0hBpO8PoGPN4U5luwfEMrw7OXLYoksRr72 xkrcpkCHM01L
gPNrDrfF4kJpLu/MbIwR1v2mdb8I5rkrr7L/l/AMCO6PG4rdfznsmuHPf1BL AQIUCxQAAAAI
AJJFWTjVHJzSpQAAADMBAAA9AAAAAAAAAAEAIAAAAAAAAABvcmcuZWNsaXBz ZS5kYXRhdG9v
bHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC8uY2xhc3NwYXRoUEsB AhQLFAAAAAgA
kkVZOGoGuCX7AAAAxwIAADsAAAAAAAAAAQAgAAAAAAEAAG9yZy5lY2xpcHNl LmRhdGF0b29s
cy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0Ly5wcm9qZWN0UEsBAhQL CgAAAAAATntZ
OAAAAAAAAAAAAAAAADcAAAAAAAAAAAAQAAAAVAIAAG9yZy5lY2xpcHNlLmRh dGF0b29scy5j
b25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L2Jpbi9QSwECFAsUAAAACACS RVk40ltg+z8A
AABQAAAAQwAAAAAAAAABACAAAACpAgAAb3JnLmVjbGlwc2UuZGF0YXRvb2xz LmNvbm5lY3Rp
dml0eS5zcW0ubG9hZGVyLnRlc3QvYnVpbGQucHJvcGVydGllc1BLAQIUCwoA AAAAAEp7WTgA
AAAAAAAAAAAAAAA8AAAAAAAAAAAAEAAAAEkDAABvcmcuZWNsaXBzZS5kYXRh dG9vbHMuY29u
bmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9NRVRBLUlORi9QSwECFAsUAAAA CAA0WVk4GlQJ
Ra0AAACEAQAARwAAAAAAAAABACAAAACjAwAAb3JnLmVjbGlwc2UuZGF0YXRv b2xzLmNvbm5l
Y3Rpdml0eS5zcW0ubG9hZGVyLnRlc3QvTUVUQS1JTkYvTUFOSUZFU1QuTUZQ SwECFAsKAAAA
AABKe1k4AAAAAAAAAAAAAAAANwAAAAAAAAAAABAAAAC1BAAAb3JnLmVjbGlw c2UuZGF0YXRv
b2xzLmNvbm5lY3Rpdml0eS5zcW0ubG9hZGVyLnRlc3Qvc3JjL1BLAQIUCwoA AAAAAEp7WTgA
AAAAAAAAAAAAAAA7AAAAAAAAAAAAEAAAAAoFAABvcmcuZWNsaXBzZS5kYXRh dG9vbHMuY29u
bmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL1BLAQIUCwoAAAAA AEp7WTgAAAAA
AAAAAAAAAABDAAAAAAAAAAAAEAAAAGMFAABvcmcuZWNsaXBzZS5kYXRhdG9v bHMuY29ubmVj
dGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2UvUEsBAhQL CgAAAAAASntZ
OAAAAAAAAAAAAAAAAE0AAAAAAAAAAAAQAAAAxAUAAG9yZy5lY2xpcHNlLmRh dGF0b29scy5j
b25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L3NyYy9vcmcvZWNsaXBzZS9k YXRhdG9vbHMv
UEsBAhQLCgAAAAAASntZOAAAAAAAAAAAAAAAAFoAAAAAAAAAAAAQAAAALwYA AG9yZy5lY2xp
cHNlLmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L3Ny Yy9vcmcvZWNs
aXBzZS9kYXRhdG9vbHMvY29ubmVjdGl2aXR5L1BLAQIUCwoAAAAAAEp7WTgA AAAAAAAAAAAA
AABeAAAAAAAAAAAAEAAAAKcGAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29u bmVjdGl2aXR5
LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nv bm5lY3Rpdml0
eS9zcW0vUEsBAhQLCgAAAAAASntZOAAAAAAAAAAAAAAAAGUAAAAAAAAAAAAQ AAAAIwcAAG9y
Zy5lY2xpcHNlLmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50 ZXN0L3NyYy9v
cmcvZWNsaXBzZS9kYXRhdG9vbHMvY29ubmVjdGl2aXR5L3NxbS9sb2FkZXIv UEsBAhQLCgAA
AAAASntZOAAAAAAAAAAAAAAAAGoAAAAAAAAAAAAQAAAApgcAAG9yZy5lY2xp cHNlLmRhdGF0
b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L3NyYy9vcmcvZWNs aXBzZS9kYXRh
dG9vbHMvY29ubmVjdGl2aXR5L3NxbS9sb2FkZXIvdGVzdC9QSwECFAsUAAAA CABLclk4066F
MwkBAAARAwAAeQAAAAAAAAABACAAAAAuCAAAb3JnLmVjbGlwc2UuZGF0YXRv b2xzLmNvbm5l
Y3Rpdml0eS5zcW0ubG9hZGVyLnRlc3Qvc3JjL29yZy9lY2xpcHNlL2RhdGF0 b29scy9jb25u
ZWN0aXZpdHkvc3FtL2xvYWRlci90ZXN0L2Jhc2UucHJvcGVydGllc1BLAQIU CxQAAAAIABF5
WTjoBgaOcwMAAH8LAACAAAAAAAAAAAEAIAAAAM4JAABvcmcuZWNsaXBzZS5k YXRhdG9vbHMu
Y29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2Uv ZGF0YXRvb2xz
L2Nvbm5lY3Rpdml0eS9zcW0vbG9hZGVyL3Rlc3QvQ2F0YWxvZ0xvYWRlclRl c3QuamF2YVBL
AQIUCxQAAAAIABJuWTiwKxmaKAEAAGUCAAB8AAAAAAAAAAEAIAAAAN8NAABv cmcuZWNsaXBz
ZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMv b3JnL2VjbGlw
c2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9zcW0vbG9hZGVyL3Rlc3QvQ29u ZmlndXJhdGlv
bi5qYXZhUEsBAhQLFAAAAAgASXdZOJkoA0WPAAAAMgEAAIIAAAAAAAAAAQAg AAAAoQ8AAG9y
Zy5lY2xpcHNlLmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50 ZXN0L3NyYy9v
cmcvZWNsaXBzZS9kYXRhdG9vbHMvY29ubmVjdGl2aXR5L3NxbS9sb2FkZXIv dGVzdC9jb25m
aWd1cmF0aW9uLnByb3BlcnRpZXNQSwECFAsUAAAACAAJe1k4pPFZxlwGAABh GQAAgQAAAAAA
AAABACAAAADQEAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xzLmNvbm5lY3Rpdml0 eS5zcW0ubG9h
ZGVyLnRlc3Qvc3JjL29yZy9lY2xpcHNlL2RhdGF0b29scy9jb25uZWN0aXZp dHkvc3FtL2xv
YWRlci90ZXN0L092ZXJyaWRlTG9hZGVyVGVzdC5qYXZhUEsFBgAAAAATABMA 4AkAAMsXAAAA
AA==
--------------030801080508090304060203--
Re: Trouble with overrideLoader [message #42004 is a reply to message #41970] Mon, 25 February 2008 15:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: brianf.sybase.com

Thanks for the test code... Let me do some playing with this and get back to
you.
--Fitz

"Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
news:fpun02$u6m$1@build.eclipse.org...
> Hello Brian,
>
> thanks for your reply. I wasn't sure if the mailing list is alive so I
> reposted the message here.
>
> I've a JUnit test for the override loader problem (the source is
> attached to this mail). It basically uses two different databases and
> retrieves the schemas for both of them. Afterwards it refreshes one of
> the databases and shows that this instance lists an additional schema
> (which belongs to the other database).
>
> To get the test running you should adjust the properties in
> configuration.properties to fit your environment (location of the Derby
> 10.1 driver, ...). The class
> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
> contains the test and should therefore run as "JUnit Plug-in Test".
> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
> can have look at the setup code :).
>
> Regarding the column loaders. I was afraid you said something like that.
> Luckily I've already derived tables, views and procedures, so I can
> easily add the column loaders.
>
> Thank you,
>
> Enrico Schenk
>
> Software Engineer
> Ingres Germany GmbH - European Technology Center
>
> Brian Fitzpatrick wrote:
>> Hi Enrico...
>>
>> Sorry I didn't get back to your mailing list posting earlier, but glad
>> you
>> reposted here.
>>
>> That's definitely an odd behavior you found with (1). I know that there
>> has
>> been some discussion of having multiple levels of override loaders with
>> priorities and such to allow for a hierarchy, so that may clear up this
>> issue in Ganymede.
>>
>> Can you provide some example code perhaps using Derby or one of the other
>> profiles to reproduce this issue? I'd be happy to look at it. Obviously
>> it
>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>
>> As for (2), yeah, I wondered about that when I wrote that code in the
>> first
>> place. Because of the way those are structured, you'd have to actually
>> override the routine loader or the table loader and provide your own
>> column
>> loader below them to avoid that problem. At this point I don't have a
>> better solution other than implementing the whole catalog loader down the
>> line.
>>
>> As for contributing your Ingres code, we'd love to have that in the
>> Enablement project part of DTP. Please contact John Graham
>> (john.graham@sybase.com) and he can help point you in the right
>> direction.
>>
>> --Brian Fitzpatrick
>> Sybase, Inc.
>> Sr. Software Engineer
>> DataTools Connectivity Lead
>>
>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>> news:fpl453$t64$1@build.eclipse.org...
>>> Hello,
>>>
>>> I am currently developing a bundle of plug-ins to provide Ingres support
>>> for DTP.
>>>
>>> At the moment I have two questions regarding to the catalog loading.
>>>
>>> 1. JDBC loader
>>>
>>> To provide additional catalog information for DTP, I use the
>>> "overrideLoader" extension point. This way I did not have to implement
>>> the
>>> entire catalog structure. After all I'm a bit unsure if I use the API as
>>> it is meant to be used. After testing the implementation of a table
>>> loader
>>> (it just replaces the view and the table factory), I have seen an
>>> unexpected result. The following steps were done in the data source
>>> explorer.
>>>
>>> 1. Loading table A's columns
>>> 2. Loading table B's columns
>>> 3. Refreshing table A's columns
>>>
>>> To my surprise I have seen the columns of table B as columns of table A
>>> (the effect occurs only when using an override loader).
>>>
>>> After having a closer look at the source code, I found out that
>>>
>>> * There is always exactly one instance of a specific override loader
>>> * The loader's instance is shared between all requesting objects (e.g.
>>> tables)
>>> * A loader has a catalog object that depends on the requesting object
>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>> instance of Table)
>>>
>>> When a object uses its cached loader, the loader is sometimes
>>> initialized
>>> with the wrong catalog object (due to sharing). Are the loaders meant to
>>> be used in a stateless way? If so, can you provide an example?
>>>
>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>
>>> JDBCProcedure.createParameterLoader() and JDBCTable.createColumnLoader()
>>> uses both the EClass of Column to find possible override loaders.
>>> Because
>>> of casting the result to the according loader (in JDBCProcedure and
>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>> table
>>> columns or procedure columns.
>>>
>>> Thanks in advance,
>>>
>>> Enrico Schenk
>>>
>>> Software Engineer
>>> Ingres Germany GmbH - European Technology Center
>>>
>>> PS: It's planned to contribute the plug-ins (including the source code)
>>> to
>>> the eclipse foundation. Can you point me in the right direction for the
>>> required steps?
>>
>>
>
>
Re: Trouble with overrideLoader [message #42035 is a reply to message #42004] Tue, 26 February 2008 21:13 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: brianf.sybase.com

Hey Enrico...

Figured it out. If you create a BZ entry for me documenting the issue, I can
get a fix in probably by tomorrow morning for 1.6 M6. The issue is that you
are absolutely correct. I'm creating one and only one instance of that
override loader and then reusing it everywhere. The fix is to create a new
instance of the class each time the loader is created, and then your test
works beautifully.

So please create a new BZ entry for me in Connectivity and I'll get this
bugger fixed. Thanks for your patience!

--Fitz

"Brian Fitzpatrick" <brianf@sybase.com> wrote in message
news:fpun77$vkv$1@build.eclipse.org...
> Thanks for the test code... Let me do some playing with this and get back
> to you.
> --Fitz
>
> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
> news:fpun02$u6m$1@build.eclipse.org...
>> Hello Brian,
>>
>> thanks for your reply. I wasn't sure if the mailing list is alive so I
>> reposted the message here.
>>
>> I've a JUnit test for the override loader problem (the source is
>> attached to this mail). It basically uses two different databases and
>> retrieves the schemas for both of them. Afterwards it refreshes one of
>> the databases and shows that this instance lists an additional schema
>> (which belongs to the other database).
>>
>> To get the test running you should adjust the properties in
>> configuration.properties to fit your environment (location of the Derby
>> 10.1 driver, ...). The class
>> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
>> contains the test and should therefore run as "JUnit Plug-in Test".
>> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
>> can have look at the setup code :).
>>
>> Regarding the column loaders. I was afraid you said something like that.
>> Luckily I've already derived tables, views and procedures, so I can
>> easily add the column loaders.
>>
>> Thank you,
>>
>> Enrico Schenk
>>
>> Software Engineer
>> Ingres Germany GmbH - European Technology Center
>>
>> Brian Fitzpatrick wrote:
>>> Hi Enrico...
>>>
>>> Sorry I didn't get back to your mailing list posting earlier, but glad
>>> you
>>> reposted here.
>>>
>>> That's definitely an odd behavior you found with (1). I know that there
>>> has
>>> been some discussion of having multiple levels of override loaders with
>>> priorities and such to allow for a hierarchy, so that may clear up this
>>> issue in Ganymede.
>>>
>>> Can you provide some example code perhaps using Derby or one of the
>>> other
>>> profiles to reproduce this issue? I'd be happy to look at it. Obviously
>>> it
>>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>>
>>> As for (2), yeah, I wondered about that when I wrote that code in the
>>> first
>>> place. Because of the way those are structured, you'd have to actually
>>> override the routine loader or the table loader and provide your own
>>> column
>>> loader below them to avoid that problem. At this point I don't have a
>>> better solution other than implementing the whole catalog loader down
>>> the
>>> line.
>>>
>>> As for contributing your Ingres code, we'd love to have that in the
>>> Enablement project part of DTP. Please contact John Graham
>>> (john.graham@sybase.com) and he can help point you in the right
>>> direction.
>>>
>>> --Brian Fitzpatrick
>>> Sybase, Inc.
>>> Sr. Software Engineer
>>> DataTools Connectivity Lead
>>>
>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>> news:fpl453$t64$1@build.eclipse.org...
>>>> Hello,
>>>>
>>>> I am currently developing a bundle of plug-ins to provide Ingres
>>>> support
>>>> for DTP.
>>>>
>>>> At the moment I have two questions regarding to the catalog loading.
>>>>
>>>> 1. JDBC loader
>>>>
>>>> To provide additional catalog information for DTP, I use the
>>>> "overrideLoader" extension point. This way I did not have to implement
>>>> the
>>>> entire catalog structure. After all I'm a bit unsure if I use the API
>>>> as
>>>> it is meant to be used. After testing the implementation of a table
>>>> loader
>>>> (it just replaces the view and the table factory), I have seen an
>>>> unexpected result. The following steps were done in the data source
>>>> explorer.
>>>>
>>>> 1. Loading table A's columns
>>>> 2. Loading table B's columns
>>>> 3. Refreshing table A's columns
>>>>
>>>> To my surprise I have seen the columns of table B as columns of table A
>>>> (the effect occurs only when using an override loader).
>>>>
>>>> After having a closer look at the source code, I found out that
>>>>
>>>> * There is always exactly one instance of a specific override loader
>>>> * The loader's instance is shared between all requesting objects (e.g.
>>>> tables)
>>>> * A loader has a catalog object that depends on the requesting object
>>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>>> instance of Table)
>>>>
>>>> When a object uses its cached loader, the loader is sometimes
>>>> initialized
>>>> with the wrong catalog object (due to sharing). Are the loaders meant
>>>> to
>>>> be used in a stateless way? If so, can you provide an example?
>>>>
>>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>>
>>>> JDBCProcedure.createParameterLoader() and
>>>> JDBCTable.createColumnLoader()
>>>> uses both the EClass of Column to find possible override loaders.
>>>> Because
>>>> of casting the result to the according loader (in JDBCProcedure and
>>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>>> table
>>>> columns or procedure columns.
>>>>
>>>> Thanks in advance,
>>>>
>>>> Enrico Schenk
>>>>
>>>> Software Engineer
>>>> Ingres Germany GmbH - European Technology Center
>>>>
>>>> PS: It's planned to contribute the plug-ins (including the source code)
>>>> to
>>>> the eclipse foundation. Can you point me in the right direction for the
>>>> required steps?
>>>
>>>
>>
>>
>
>
Re: Trouble with overrideLoader [message #42097 is a reply to message #42035] Tue, 26 February 2008 21:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: brianf.sybase.com

Never mind... I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=220464

I'll get this checked in and it should appear in tomorrow's build.

--Fitz

"Brian Fitzpatrick" <brianf@sybase.com> wrote in message
news:fq1vdv$6ep$1@build.eclipse.org...
> Hey Enrico...
>
> Figured it out. If you create a BZ entry for me documenting the issue, I
> can get a fix in probably by tomorrow morning for 1.6 M6. The issue is
> that you are absolutely correct. I'm creating one and only one instance of
> that override loader and then reusing it everywhere. The fix is to create
> a new instance of the class each time the loader is created, and then your
> test works beautifully.
>
> So please create a new BZ entry for me in Connectivity and I'll get this
> bugger fixed. Thanks for your patience!
>
> --Fitz
>
> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
> news:fpun77$vkv$1@build.eclipse.org...
>> Thanks for the test code... Let me do some playing with this and get back
>> to you.
>> --Fitz
>>
>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>> news:fpun02$u6m$1@build.eclipse.org...
>>> Hello Brian,
>>>
>>> thanks for your reply. I wasn't sure if the mailing list is alive so I
>>> reposted the message here.
>>>
>>> I've a JUnit test for the override loader problem (the source is
>>> attached to this mail). It basically uses two different databases and
>>> retrieves the schemas for both of them. Afterwards it refreshes one of
>>> the databases and shows that this instance lists an additional schema
>>> (which belongs to the other database).
>>>
>>> To get the test running you should adjust the properties in
>>> configuration.properties to fit your environment (location of the Derby
>>> 10.1 driver, ...). The class
>>> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
>>> contains the test and should therefore run as "JUnit Plug-in Test".
>>> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
>>> can have look at the setup code :).
>>>
>>> Regarding the column loaders. I was afraid you said something like that.
>>> Luckily I've already derived tables, views and procedures, so I can
>>> easily add the column loaders.
>>>
>>> Thank you,
>>>
>>> Enrico Schenk
>>>
>>> Software Engineer
>>> Ingres Germany GmbH - European Technology Center
>>>
>>> Brian Fitzpatrick wrote:
>>>> Hi Enrico...
>>>>
>>>> Sorry I didn't get back to your mailing list posting earlier, but glad
>>>> you
>>>> reposted here.
>>>>
>>>> That's definitely an odd behavior you found with (1). I know that there
>>>> has
>>>> been some discussion of having multiple levels of override loaders with
>>>> priorities and such to allow for a hierarchy, so that may clear up this
>>>> issue in Ganymede.
>>>>
>>>> Can you provide some example code perhaps using Derby or one of the
>>>> other
>>>> profiles to reproduce this issue? I'd be happy to look at it. Obviously
>>>> it
>>>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>>>
>>>> As for (2), yeah, I wondered about that when I wrote that code in the
>>>> first
>>>> place. Because of the way those are structured, you'd have to actually
>>>> override the routine loader or the table loader and provide your own
>>>> column
>>>> loader below them to avoid that problem. At this point I don't have a
>>>> better solution other than implementing the whole catalog loader down
>>>> the
>>>> line.
>>>>
>>>> As for contributing your Ingres code, we'd love to have that in the
>>>> Enablement project part of DTP. Please contact John Graham
>>>> (john.graham@sybase.com) and he can help point you in the right
>>>> direction.
>>>>
>>>> --Brian Fitzpatrick
>>>> Sybase, Inc.
>>>> Sr. Software Engineer
>>>> DataTools Connectivity Lead
>>>>
>>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>>> news:fpl453$t64$1@build.eclipse.org...
>>>>> Hello,
>>>>>
>>>>> I am currently developing a bundle of plug-ins to provide Ingres
>>>>> support
>>>>> for DTP.
>>>>>
>>>>> At the moment I have two questions regarding to the catalog loading.
>>>>>
>>>>> 1. JDBC loader
>>>>>
>>>>> To provide additional catalog information for DTP, I use the
>>>>> "overrideLoader" extension point. This way I did not have to implement
>>>>> the
>>>>> entire catalog structure. After all I'm a bit unsure if I use the API
>>>>> as
>>>>> it is meant to be used. After testing the implementation of a table
>>>>> loader
>>>>> (it just replaces the view and the table factory), I have seen an
>>>>> unexpected result. The following steps were done in the data source
>>>>> explorer.
>>>>>
>>>>> 1. Loading table A's columns
>>>>> 2. Loading table B's columns
>>>>> 3. Refreshing table A's columns
>>>>>
>>>>> To my surprise I have seen the columns of table B as columns of table
>>>>> A
>>>>> (the effect occurs only when using an override loader).
>>>>>
>>>>> After having a closer look at the source code, I found out that
>>>>>
>>>>> * There is always exactly one instance of a specific override loader
>>>>> * The loader's instance is shared between all requesting objects (e.g.
>>>>> tables)
>>>>> * A loader has a catalog object that depends on the requesting object
>>>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>>>> instance of Table)
>>>>>
>>>>> When a object uses its cached loader, the loader is sometimes
>>>>> initialized
>>>>> with the wrong catalog object (due to sharing). Are the loaders meant
>>>>> to
>>>>> be used in a stateless way? If so, can you provide an example?
>>>>>
>>>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>>>
>>>>> JDBCProcedure.createParameterLoader() and
>>>>> JDBCTable.createColumnLoader()
>>>>> uses both the EClass of Column to find possible override loaders.
>>>>> Because
>>>>> of casting the result to the according loader (in JDBCProcedure and
>>>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>>>> table
>>>>> columns or procedure columns.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Enrico Schenk
>>>>>
>>>>> Software Engineer
>>>>> Ingres Germany GmbH - European Technology Center
>>>>>
>>>>> PS: It's planned to contribute the plug-ins (including the source
>>>>> code) to
>>>>> the eclipse foundation. Can you point me in the right direction for
>>>>> the
>>>>> required steps?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Trouble with overrideLoader [message #42296 is a reply to message #42097] Wed, 27 February 2008 16:10 Go to previous messageGo to next message
Enrico Schenk is currently offline Enrico SchenkFriend
Messages: 23
Registered: July 2009
Junior Member
Thanks Brian, with the patch it works like a charm :)

Enrico

Brian Fitzpatrick wrote:
> Never mind... I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=220464
>
> I'll get this checked in and it should appear in tomorrow's build.
>
> --Fitz
>
> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
> news:fq1vdv$6ep$1@build.eclipse.org...
>> Hey Enrico...
>>
>> Figured it out. If you create a BZ entry for me documenting the issue, I
>> can get a fix in probably by tomorrow morning for 1.6 M6. The issue is
>> that you are absolutely correct. I'm creating one and only one instance of
>> that override loader and then reusing it everywhere. The fix is to create
>> a new instance of the class each time the loader is created, and then your
>> test works beautifully.
>>
>> So please create a new BZ entry for me in Connectivity and I'll get this
>> bugger fixed. Thanks for your patience!
>>
>> --Fitz
>>
>> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
>> news:fpun77$vkv$1@build.eclipse.org...
>>> Thanks for the test code... Let me do some playing with this and get back
>>> to you.
>>> --Fitz
>>>
>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>> news:fpun02$u6m$1@build.eclipse.org...
>>>> Hello Brian,
>>>>
>>>> thanks for your reply. I wasn't sure if the mailing list is alive so I
>>>> reposted the message here.
>>>>
>>>> I've a JUnit test for the override loader problem (the source is
>>>> attached to this mail). It basically uses two different databases and
>>>> retrieves the schemas for both of them. Afterwards it refreshes one of
>>>> the databases and shows that this instance lists an additional schema
>>>> (which belongs to the other database).
>>>>
>>>> To get the test running you should adjust the properties in
>>>> configuration.properties to fit your environment (location of the Derby
>>>> 10.1 driver, ...). The class
>>>> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
>>>> contains the test and should therefore run as "JUnit Plug-in Test".
>>>> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
>>>> can have look at the setup code :).
>>>>
>>>> Regarding the column loaders. I was afraid you said something like that.
>>>> Luckily I've already derived tables, views and procedures, so I can
>>>> easily add the column loaders.
>>>>
>>>> Thank you,
>>>>
>>>> Enrico Schenk
>>>>
>>>> Software Engineer
>>>> Ingres Germany GmbH - European Technology Center
>>>>
>>>> Brian Fitzpatrick wrote:
>>>>> Hi Enrico...
>>>>>
>>>>> Sorry I didn't get back to your mailing list posting earlier, but glad
>>>>> you
>>>>> reposted here.
>>>>>
>>>>> That's definitely an odd behavior you found with (1). I know that there
>>>>> has
>>>>> been some discussion of having multiple levels of override loaders with
>>>>> priorities and such to allow for a hierarchy, so that may clear up this
>>>>> issue in Ganymede.
>>>>>
>>>>> Can you provide some example code perhaps using Derby or one of the
>>>>> other
>>>>> profiles to reproduce this issue? I'd be happy to look at it. Obviously
>>>>> it
>>>>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>>>>
>>>>> As for (2), yeah, I wondered about that when I wrote that code in the
>>>>> first
>>>>> place. Because of the way those are structured, you'd have to actually
>>>>> override the routine loader or the table loader and provide your own
>>>>> column
>>>>> loader below them to avoid that problem. At this point I don't have a
>>>>> better solution other than implementing the whole catalog loader down
>>>>> the
>>>>> line.
>>>>>
>>>>> As for contributing your Ingres code, we'd love to have that in the
>>>>> Enablement project part of DTP. Please contact John Graham
>>>>> (john.graham@sybase.com) and he can help point you in the right
>>>>> direction.
>>>>>
>>>>> --Brian Fitzpatrick
>>>>> Sybase, Inc.
>>>>> Sr. Software Engineer
>>>>> DataTools Connectivity Lead
>>>>>
>>>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>>>> news:fpl453$t64$1@build.eclipse.org...
>>>>>> Hello,
>>>>>>
>>>>>> I am currently developing a bundle of plug-ins to provide Ingres
>>>>>> support
>>>>>> for DTP.
>>>>>>
>>>>>> At the moment I have two questions regarding to the catalog loading.
>>>>>>
>>>>>> 1. JDBC loader
>>>>>>
>>>>>> To provide additional catalog information for DTP, I use the
>>>>>> "overrideLoader" extension point. This way I did not have to implement
>>>>>> the
>>>>>> entire catalog structure. After all I'm a bit unsure if I use the API
>>>>>> as
>>>>>> it is meant to be used. After testing the implementation of a table
>>>>>> loader
>>>>>> (it just replaces the view and the table factory), I have seen an
>>>>>> unexpected result. The following steps were done in the data source
>>>>>> explorer.
>>>>>>
>>>>>> 1. Loading table A's columns
>>>>>> 2. Loading table B's columns
>>>>>> 3. Refreshing table A's columns
>>>>>>
>>>>>> To my surprise I have seen the columns of table B as columns of table
>>>>>> A
>>>>>> (the effect occurs only when using an override loader).
>>>>>>
>>>>>> After having a closer look at the source code, I found out that
>>>>>>
>>>>>> * There is always exactly one instance of a specific override loader
>>>>>> * The loader's instance is shared between all requesting objects (e.g.
>>>>>> tables)
>>>>>> * A loader has a catalog object that depends on the requesting object
>>>>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>>>>> instance of Table)
>>>>>>
>>>>>> When a object uses its cached loader, the loader is sometimes
>>>>>> initialized
>>>>>> with the wrong catalog object (due to sharing). Are the loaders meant
>>>>>> to
>>>>>> be used in a stateless way? If so, can you provide an example?
>>>>>>
>>>>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>>>>
>>>>>> JDBCProcedure.createParameterLoader() and
>>>>>> JDBCTable.createColumnLoader()
>>>>>> uses both the EClass of Column to find possible override loaders.
>>>>>> Because
>>>>>> of casting the result to the according loader (in JDBCProcedure and
>>>>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>>>>> table
>>>>>> columns or procedure columns.
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> Enrico Schenk
>>>>>>
>>>>>> Software Engineer
>>>>>> Ingres Germany GmbH - European Technology Center
>>>>>>
>>>>>> PS: It's planned to contribute the plug-ins (including the source
>>>>>> code) to
>>>>>> the eclipse foundation. Can you point me in the right direction for
>>>>>> the
>>>>>> required steps?
>>>>>
>>>>
>>>
>>
>
>
Re: Trouble with overrideLoader [message #42321 is a reply to message #42296] Wed, 27 February 2008 20:07 Go to previous message
Eclipse UserFriend
Originally posted by: brianf.sybase.com

Great news! Glad we could help! Let us know if you need anything else.
--Fitz

"Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
news:fq420r$k1i$1@build.eclipse.org...
> Thanks Brian, with the patch it works like a charm :)
>
> Enrico
>
> Brian Fitzpatrick wrote:
>> Never mind... I created
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=220464
>>
>> I'll get this checked in and it should appear in tomorrow's build.
>>
>> --Fitz
>>
>> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
>> news:fq1vdv$6ep$1@build.eclipse.org...
>>> Hey Enrico...
>>>
>>> Figured it out. If you create a BZ entry for me documenting the issue, I
>>> can get a fix in probably by tomorrow morning for 1.6 M6. The issue is
>>> that you are absolutely correct. I'm creating one and only one instance
>>> of that override loader and then reusing it everywhere. The fix is to
>>> create a new instance of the class each time the loader is created, and
>>> then your test works beautifully.
>>>
>>> So please create a new BZ entry for me in Connectivity and I'll get this
>>> bugger fixed. Thanks for your patience!
>>>
>>> --Fitz
>>>
>>> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
>>> news:fpun77$vkv$1@build.eclipse.org...
>>>> Thanks for the test code... Let me do some playing with this and get
>>>> back to you.
>>>> --Fitz
>>>>
>>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>>> news:fpun02$u6m$1@build.eclipse.org...
>>>>> Hello Brian,
>>>>>
>>>>> thanks for your reply. I wasn't sure if the mailing list is alive so I
>>>>> reposted the message here.
>>>>>
>>>>> I've a JUnit test for the override loader problem (the source is
>>>>> attached to this mail). It basically uses two different databases and
>>>>> retrieves the schemas for both of them. Afterwards it refreshes one of
>>>>> the databases and shows that this instance lists an additional schema
>>>>> (which belongs to the other database).
>>>>>
>>>>> To get the test running you should adjust the properties in
>>>>> configuration.properties to fit your environment (location of the
>>>>> Derby
>>>>> 10.1 driver, ...). The class
>>>>> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
>>>>> contains the test and should therefore run as "JUnit Plug-in Test".
>>>>> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
>>>>> can have look at the setup code :).
>>>>>
>>>>> Regarding the column loaders. I was afraid you said something like
>>>>> that.
>>>>> Luckily I've already derived tables, views and procedures, so I can
>>>>> easily add the column loaders.
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Enrico Schenk
>>>>>
>>>>> Software Engineer
>>>>> Ingres Germany GmbH - European Technology Center
>>>>>
>>>>> Brian Fitzpatrick wrote:
>>>>>> Hi Enrico...
>>>>>>
>>>>>> Sorry I didn't get back to your mailing list posting earlier, but
>>>>>> glad you
>>>>>> reposted here.
>>>>>>
>>>>>> That's definitely an odd behavior you found with (1). I know that
>>>>>> there has
>>>>>> been some discussion of having multiple levels of override loaders
>>>>>> with
>>>>>> priorities and such to allow for a hierarchy, so that may clear up
>>>>>> this
>>>>>> issue in Ganymede.
>>>>>>
>>>>>> Can you provide some example code perhaps using Derby or one of the
>>>>>> other
>>>>>> profiles to reproduce this issue? I'd be happy to look at it.
>>>>>> Obviously it
>>>>>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>>>>>
>>>>>> As for (2), yeah, I wondered about that when I wrote that code in the
>>>>>> first
>>>>>> place. Because of the way those are structured, you'd have to
>>>>>> actually
>>>>>> override the routine loader or the table loader and provide your own
>>>>>> column
>>>>>> loader below them to avoid that problem. At this point I don't have
>>>>>> a
>>>>>> better solution other than implementing the whole catalog loader down
>>>>>> the
>>>>>> line.
>>>>>>
>>>>>> As for contributing your Ingres code, we'd love to have that in the
>>>>>> Enablement project part of DTP. Please contact John Graham
>>>>>> (john.graham@sybase.com) and he can help point you in the right
>>>>>> direction.
>>>>>>
>>>>>> --Brian Fitzpatrick
>>>>>> Sybase, Inc.
>>>>>> Sr. Software Engineer
>>>>>> DataTools Connectivity Lead
>>>>>>
>>>>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>>>>> news:fpl453$t64$1@build.eclipse.org...
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am currently developing a bundle of plug-ins to provide Ingres
>>>>>>> support
>>>>>>> for DTP.
>>>>>>>
>>>>>>> At the moment I have two questions regarding to the catalog loading.
>>>>>>>
>>>>>>> 1. JDBC loader
>>>>>>>
>>>>>>> To provide additional catalog information for DTP, I use the
>>>>>>> "overrideLoader" extension point. This way I did not have to
>>>>>>> implement the
>>>>>>> entire catalog structure. After all I'm a bit unsure if I use the
>>>>>>> API as
>>>>>>> it is meant to be used. After testing the implementation of a table
>>>>>>> loader
>>>>>>> (it just replaces the view and the table factory), I have seen an
>>>>>>> unexpected result. The following steps were done in the data source
>>>>>>> explorer.
>>>>>>>
>>>>>>> 1. Loading table A's columns
>>>>>>> 2. Loading table B's columns
>>>>>>> 3. Refreshing table A's columns
>>>>>>>
>>>>>>> To my surprise I have seen the columns of table B as columns of
>>>>>>> table A
>>>>>>> (the effect occurs only when using an override loader).
>>>>>>>
>>>>>>> After having a closer look at the source code, I found out that
>>>>>>>
>>>>>>> * There is always exactly one instance of a specific override loader
>>>>>>> * The loader's instance is shared between all requesting objects
>>>>>>> (e.g.
>>>>>>> tables)
>>>>>>> * A loader has a catalog object that depends on the requesting
>>>>>>> object
>>>>>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>>>>>> instance of Table)
>>>>>>>
>>>>>>> When a object uses its cached loader, the loader is sometimes
>>>>>>> initialized
>>>>>>> with the wrong catalog object (due to sharing). Are the loaders
>>>>>>> meant to
>>>>>>> be used in a stateless way? If so, can you provide an example?
>>>>>>>
>>>>>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>>>>>
>>>>>>> JDBCProcedure.createParameterLoader() and
>>>>>>> JDBCTable.createColumnLoader()
>>>>>>> uses both the EClass of Column to find possible override loaders.
>>>>>>> Because
>>>>>>> of casting the result to the according loader (in JDBCProcedure and
>>>>>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>>>>>> table
>>>>>>> columns or procedure columns.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Enrico Schenk
>>>>>>>
>>>>>>> Software Engineer
>>>>>>> Ingres Germany GmbH - European Technology Center
>>>>>>>
>>>>>>> PS: It's planned to contribute the plug-ins (including the source
>>>>>>> code) to
>>>>>>> the eclipse foundation. Can you point me in the right direction for
>>>>>>> the
>>>>>>> required steps?
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Trouble with overrideLoader [message #590031 is a reply to message #41809] Fri, 22 February 2008 15:36 Go to previous message
Brian Fitzpatrick is currently offline Brian FitzpatrickFriend
Messages: 500
Registered: July 2009
Senior Member
Hi Enrico...

Sorry I didn't get back to your mailing list posting earlier, but glad you
reposted here.

That's definitely an odd behavior you found with (1). I know that there has
been some discussion of having multiple levels of override loaders with
priorities and such to allow for a hierarchy, so that may clear up this
issue in Ganymede.

Can you provide some example code perhaps using Derby or one of the other
profiles to reproduce this issue? I'd be happy to look at it. Obviously it
warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.

As for (2), yeah, I wondered about that when I wrote that code in the first
place. Because of the way those are structured, you'd have to actually
override the routine loader or the table loader and provide your own column
loader below them to avoid that problem. At this point I don't have a
better solution other than implementing the whole catalog loader down the
line.

As for contributing your Ingres code, we'd love to have that in the
Enablement project part of DTP. Please contact John Graham
(john.graham@sybase.com) and he can help point you in the right direction.

--Brian Fitzpatrick
Sybase, Inc.
Sr. Software Engineer
DataTools Connectivity Lead

"Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
news:fpl453$t64$1@build.eclipse.org...
> Hello,
>
> I am currently developing a bundle of plug-ins to provide Ingres support
> for DTP.
>
> At the moment I have two questions regarding to the catalog loading.
>
> 1. JDBC loader
>
> To provide additional catalog information for DTP, I use the
> "overrideLoader" extension point. This way I did not have to implement the
> entire catalog structure. After all I'm a bit unsure if I use the API as
> it is meant to be used. After testing the implementation of a table loader
> (it just replaces the view and the table factory), I have seen an
> unexpected result. The following steps were done in the data source
> explorer.
>
> 1. Loading table A's columns
> 2. Loading table B's columns
> 3. Refreshing table A's columns
>
> To my surprise I have seen the columns of table B as columns of table A
> (the effect occurs only when using an override loader).
>
> After having a closer look at the source code, I found out that
>
> * There is always exactly one instance of a specific override loader
> * The loader's instance is shared between all requesting objects (e.g.
> tables)
> * A loader has a catalog object that depends on the requesting object
> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
> instance of Table)
>
> When a object uses its cached loader, the loader is sometimes initialized
> with the wrong catalog object (due to sharing). Are the loaders meant to
> be used in a stateless way? If so, can you provide an example?
>
> 2. ProcedureColumnLoader and TableColumnLoader
>
> JDBCProcedure.createParameterLoader() and JDBCTable.createColumnLoader()
> uses both the EClass of Column to find possible override loaders. Because
> of casting the result to the according loader (in JDBCProcedure and
> JDBCTable), I get some class cast exceptions when trying to retrieve table
> columns or procedure columns.
>
> Thanks in advance,
>
> Enrico Schenk
>
> Software Engineer
> Ingres Germany GmbH - European Technology Center
>
> PS: It's planned to contribute the plug-ins (including the source code) to
> the eclipse foundation. Can you point me in the right direction for the
> required steps?
Re: Trouble with overrideLoader [message #590067 is a reply to message #41848] Mon, 25 February 2008 15:31 Go to previous message
Enrico Schenk is currently offline Enrico SchenkFriend
Messages: 23
Registered: July 2009
Junior Member
This is a multi-part message in MIME format.
--------------030801080508090304060203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello Brian,

thanks for your reply. I wasn't sure if the mailing list is alive so I
reposted the message here.

I've a JUnit test for the override loader problem (the source is
attached to this mail). It basically uses two different databases and
retrieves the schemas for both of them. Afterwards it refreshes one of
the databases and shows that this instance lists an additional schema
(which belongs to the other database).

To get the test running you should adjust the properties in
configuration.properties to fit your environment (location of the Derby
10.1 driver, ...). The class
org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
contains the test and should therefore run as "JUnit Plug-in Test".
Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
can have look at the setup code :).

Regarding the column loaders. I was afraid you said something like that.
Luckily I've already derived tables, views and procedures, so I can
easily add the column loaders.

Thank you,

Enrico Schenk

Software Engineer
Ingres Germany GmbH - European Technology Center

Brian Fitzpatrick wrote:
> Hi Enrico...
>
> Sorry I didn't get back to your mailing list posting earlier, but glad you
> reposted here.
>
> That's definitely an odd behavior you found with (1). I know that there has
> been some discussion of having multiple levels of override loaders with
> priorities and such to allow for a hierarchy, so that may clear up this
> issue in Ganymede.
>
> Can you provide some example code perhaps using Derby or one of the other
> profiles to reproduce this issue? I'd be happy to look at it. Obviously it
> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>
> As for (2), yeah, I wondered about that when I wrote that code in the first
> place. Because of the way those are structured, you'd have to actually
> override the routine loader or the table loader and provide your own column
> loader below them to avoid that problem. At this point I don't have a
> better solution other than implementing the whole catalog loader down the
> line.
>
> As for contributing your Ingres code, we'd love to have that in the
> Enablement project part of DTP. Please contact John Graham
> (john.graham@sybase.com) and he can help point you in the right direction.
>
> --Brian Fitzpatrick
> Sybase, Inc.
> Sr. Software Engineer
> DataTools Connectivity Lead
>
> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
> news:fpl453$t64$1@build.eclipse.org...
>> Hello,
>>
>> I am currently developing a bundle of plug-ins to provide Ingres support
>> for DTP.
>>
>> At the moment I have two questions regarding to the catalog loading.
>>
>> 1. JDBC loader
>>
>> To provide additional catalog information for DTP, I use the
>> "overrideLoader" extension point. This way I did not have to implement the
>> entire catalog structure. After all I'm a bit unsure if I use the API as
>> it is meant to be used. After testing the implementation of a table loader
>> (it just replaces the view and the table factory), I have seen an
>> unexpected result. The following steps were done in the data source
>> explorer.
>>
>> 1. Loading table A's columns
>> 2. Loading table B's columns
>> 3. Refreshing table A's columns
>>
>> To my surprise I have seen the columns of table B as columns of table A
>> (the effect occurs only when using an override loader).
>>
>> After having a closer look at the source code, I found out that
>>
>> * There is always exactly one instance of a specific override loader
>> * The loader's instance is shared between all requesting objects (e.g.
>> tables)
>> * A loader has a catalog object that depends on the requesting object
>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>> instance of Table)
>>
>> When a object uses its cached loader, the loader is sometimes initialized
>> with the wrong catalog object (due to sharing). Are the loaders meant to
>> be used in a stateless way? If so, can you provide an example?
>>
>> 2. ProcedureColumnLoader and TableColumnLoader
>>
>> JDBCProcedure.createParameterLoader() and JDBCTable.createColumnLoader()
>> uses both the EClass of Column to find possible override loaders. Because
>> of casting the result to the according loader (in JDBCProcedure and
>> JDBCTable), I get some class cast exceptions when trying to retrieve table
>> columns or procedure columns.
>>
>> Thanks in advance,
>>
>> Enrico Schenk
>>
>> Software Engineer
>> Ingres Germany GmbH - European Technology Center
>>
>> PS: It's planned to contribute the plug-ins (including the source code) to
>> the eclipse foundation. Can you point me in the right direction for the
>> required steps?
>
>


--------------030801080508090304060203
Content-Type: application/x-zip-compressed;
name="org.eclipse.datatools.connectivity.sqm.loader.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="org.eclipse.datatools.connectivity.sqm.loader.zip "

UEsDBBQAAAAIAJJFWTjVHJzSpQAAADMBAAA9AAAAb3JnLmVjbGlwc2UuZGF0 YXRvb2xzLmNv
bm5lY3Rpdml0eS5zcW0ubG9hZGVyLnRlc3QvLmNsYXNzcGF0aJ2PPQvCMBRF ZwX/Q8huqptD
axGpoEOVUmepyaONxpeYD9F/b1WKLjq4vXs5nMuL0+tJkQtYJzUmdMxGlABy LSTWCd2Wi+GE
ptNBP+aqcs5UvmlD750Avb2Ro0SRUGc5JY/ydUbfSa6xI7WtGXAljQN2EJ6p KiBv2nW2KrLd
fJ2Xs2WeFX/YjADGtQVm4RykBbFRoZbofql08Cb4zraX+ITj6PP7O1BLAwQU AAAACACSRVk4
aga4JfsAAADHAgAAOwAAAG9yZy5lY2xpcHNlLmRhdGF0b29scy5jb25uZWN0 aXZpdHkuc3Ft
LmxvYWRlci50ZXN0Ly5wcm9qZWN0vZLPTsQgEMbPmvgOm96F9eaB7SZq9qYx WX0AhLGygQFh
2ujbC9hqmmriwextvo/5+A1/xPbN2dUAMRmPm+aCrZsVoPLaYLdpHh9255fN tj07FSH6Ayi6
gaSiCZS7s3siUDpofewYKGtCAqYlSfLeJqY8Yk6YwdA7S6+OWS81REaQSPAa LDso7xwgtYJP
VXFHXKqCz9RTb6zeB1BFjfI6RyXq6vww1EFTHifmQg6yBiB+j5ATMnZ9YadR 87kh+ILyJ27Q
wG4lmud85KvjYvfqBZz8F+joTFeeedRHGLs/xQJ/b/vO4F1dLPTa9Ftg9jy4 yEx1IX79hflH
/ABQSwMECgAAAAAATntZOAAAAAAAAAAAAAAAADcAAABvcmcuZWNsaXBzZS5k YXRhdG9vbHMu
Y29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9iaW4vUEsDBBQAAAAIAJJF WTjSW2D7PwAA
AFAAAABDAAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xzLmNvbm5lY3Rpdml0eS5z cW0ubG9hZGVy
LnRlc3QvYnVpbGQucHJvcGVydGllcyvOLy1KTtXTU7BVKC5K1uflyi8tKSgt AQskZeYBBYCk
XmZeck5pSmoxUNDXNcRR19PPTV8nhpdLARXo8XIBAFBLAwQKAAAAAABKe1k4 AAAAAAAAAAAA
AAAAPAAAAG9yZy5lY2xpcHNlLmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3Ft LmxvYWRlci50
ZXN0L01FVEEtSU5GL1BLAwQUAAAACAA0WVk4GlQJRa0AAACEAQAARwAAAG9y Zy5lY2xpcHNl
LmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L01FVEEt SU5GL01BTklG
RVNULk1GjY4xDsIwDEX3nqIHIBEgpo7sRQgQe5qYyiiJaeIg9fYE2iIYKnWz /J6/f6083iCy
uEKISL4qN3Jd7JM3FkQ9wi/bTuSgHFTlJbPyaFMr0E/k3LuGLOrBoNBK0BYf EaRRrJjIRqnJ
e9CMT+Rexs5JS8pAkJzzppzfPrnRCbqEAcRA/4M1BZAheUYHq2Lpz/fVIntW cmTANirvYmdH
65488m72JIvDAAaZwqdE8QJQSwMECgAAAAAASntZOAAAAAAAAAAAAAAAADcA AABvcmcuZWNs
aXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9z cmMvUEsDBAoA
AAAAAEp7WTgAAAAAAAAAAAAAAAA7AAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xz LmNvbm5lY3Rp
dml0eS5zcW0ubG9hZGVyLnRlc3Qvc3JjL29yZy9QSwMECgAAAAAASntZOAAA AAAAAAAAAAAA
AEMAAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5s b2FkZXIudGVz
dC9zcmMvb3JnL2VjbGlwc2UvUEsDBAoAAAAAAEp7WTgAAAAAAAAAAAAAAABN AAAAb3JnLmVj
bGlwc2UuZGF0YXRvb2xzLmNvbm5lY3Rpdml0eS5zcW0ubG9hZGVyLnRlc3Qv c3JjL29yZy9l
Y2xpcHNlL2RhdGF0b29scy9QSwMECgAAAAAASntZOAAAAAAAAAAAAAAAAFoA AABvcmcuZWNs
aXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9z cmMvb3JnL2Vj
bGlwc2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9QSwMECgAAAAAASntZOAAA AAAAAAAAAAAA
AF4AAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5s b2FkZXIudGVz
dC9zcmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9zcW0v UEsDBAoAAAAA
AEp7WTgAAAAAAAAAAAAAAABlAAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xzLmNv bm5lY3Rpdml0
eS5zcW0ubG9hZGVyLnRlc3Qvc3JjL29yZy9lY2xpcHNlL2RhdGF0b29scy9j b25uZWN0aXZp
dHkvc3FtL2xvYWRlci9QSwMECgAAAAAASntZOAAAAAAAAAAAAAAAAGoAAABv cmcuZWNsaXBz
ZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMv b3JnL2VjbGlw
c2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9zcW0vbG9hZGVyL3Rlc3QvUEsD BBQAAAAIAEty
WTjTroUzCQEAABEDAAB5AAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xzLmNvbm5l Y3Rpdml0eS5z
cW0ubG9hZGVyLnRlc3Qvc3JjL29yZy9lY2xpcHNlL2RhdGF0b29scy9jb25u ZWN0aXZpdHkv
c3FtL2xvYWRlci90ZXN0L2Jhc2UucHJvcGVydGllc5WSz07DMAzG70i8Q5/A Wq9FObBmB1CH
Khji0kv+eCOoTSInK+rbk2Yb5+zoxJ/9+2w7OgGq0fiAoEUU0bkxgHLWoopm NnEBLf9jZ3ty
HikaDOzxwRWJg5ix/+Is0hnLNGRmpAAaj/aweGQlGpnSSS71poYTWiSjeC5z wMmPIqbOP4I6
EyLLeZCiMhgJ54BkxYTFji8G2lGEkNmFF+ob4dpYSwW7SaLWqC+MxXXTjxQB 31aYj+d93+3K
pLkLx6OxZl3iC2f89mSBr1jVjah65du2uo/LJ6O/jnTxgD7fO7bOockjadpm GDIFvxoMw7Bf
+PZJEabV3XE5EtbLSRZZvYG6XGO1I5YR/gBQSwMEFAAAAAgAEXlZOOgGBo5z AwAAfwsAAIAA
AABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2Fk ZXIudGVzdC9z
cmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9zcW0vbG9h ZGVyL3Rlc3Qv
Q2F0YWxvZ0xvYWRlclRlc3QuamF2YaVWTU/jMBA9F2n/g4U4pKi42nNVafvB ISso1ZY9Izd2
W7NJHGynpVrx33f8kTQmQCl72Cwez7wZz7xntyDJH7JmSMg1ZknKC8UwJZpo IVKFE5HnLNF8
y/Ueq6cMp4JQJrFmSg++nX0741khpEaPZEtwqXmK51IUTGrOVHP/E+gTvxA5 QKx4yq6fE1aY
9eAUmLiFc1K4j7klOTRFnhRKJd8yqfDU/h/nSpM8OS17CPE/RcR+DvsF018C aMTHWZF+CeOR
LhMc/5yOJ62hgMH0R6tjwJmgLF0SsKmnFKtkwzKCp7BtbMeCIaQqT7I6KqYs 13zFj7c2jC9c
6RVHfgPdLceLcpnyBCUpUQpNIDgV6xurk3uQCfprfDr9y0v4oks0kYyAfBDJ KQqpglZSZEhv
GFqDOUdEa8mXZeVMKFV217XXoWlhTQFhMLoHk2RPpUnPFeLrHOqnPcRXiPhw tON6c0jm0Dhk
SaE+ukfsmSutsLO774+CSJKhnGQsMHAaLIv6BrDmPnx9h7YCEiT2/K7gaAEn zNcWsof8gkOh
h1ukAdc1rex04BBReN41cNT3MOqaVdjX8T6eRpx20XCI8jJNPU6nqZEqjf0b 3NgOzUMFRK5I
wBnY6EYAVkwfKo7MARpVW45AwKth03DpcoY+USOHz/rRwYEgr+LDHA7iBT4v 71DS1mD+US8V
5DmPVkK+yUyMRivN5I5IICdxcEkt9jqsggEyuvlTS2mzBaIRCbemSqBILB8B wHNSAZV1KXNG
HbEbWLnQNZ7ldrUXkrtB2ZDeME7oDRisr7UZBjYylMqUWh/xU3qA8C0H9ceh LqqeHpjit93x
/EJvpNjBNfLua/haVHXTvLD88k1pHSoLJNaurIuO1uFE1O/7vND8xtzfpo2p xc49uCKsoMN3
t61ovz/ezwDDSrElZ39GylQiuStxiM7PB6jfv5jdza5mN4ur7xdNV5gLvAQe +l3nJbwAjADp
Sy18O8B3RVL7/oDDh7W77ngXf4c0SuwFM2kPohcW2WtWUevZDwISu/ehYgSv Hzrj0f5lVI9p
iL7Qf5u9arpPaXYBzeOawHFwnBrMXmvRkd8GeDq6H41Hi+uH2ej2+mH+627+ EE+DxD5TO6+t
07m23/263obJX8CtjaiRohcctLrZnX6rFpqfBfYNqoTYzmXLsnN7+QdQSwME FAAAAAgAEm5Z
OLArGZooAQAAZQIAAHwAAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVj dGl2aXR5LnNx
bS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nvbm5l Y3Rpdml0eS9z
cW0vbG9hZGVyL3Rlc3QvQ29uZmlndXJhdGlvbi5qYXZhlVFNawIxED0r+B+m IrhSjPS89FDt
3nSFFc+SxnGbGpM0mZUuxf/erLHYLfZQCOGRvHkfieViz0sE40qGQknrkW05 cTJGeSaM1ihI
HiXVzL8fmDJ8i44Rekp73V5XHqxxBG/8yFlFUrGF9F7qskBvKicw+xBoSRqd 3uB+k6aV3io8
69nqRUkBQnHvYWb0TpaV440AfPa6HevkkROCDwEDbSc1V7AiFxxhus6f59km f1pk8Aj9/xdq
Lq9+/RQmk0G+zMf5fDV+GDTpbvu3a0CRrZbrYpZtYqCQpU1gJVJEyY/Io7Rl 0KqejM7lT5ER
X+iS4NI9SEaUXA72WMehDrk6go5Dqpz+nY9dZ5uhtKGeQHASr5D89ZuAo7bo 8G4I941r2AOO
KjFzWF9QSwMEFAAAAAgASXdZOJkoA0WPAAAAMgEAAIIAAABvcmcuZWNsaXBz ZS5kYXRhdG9v
bHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlw c2UvZGF0YXRv
b2xzL2Nvbm5lY3Rpdml0eS9zcW0vbG9hZGVyL3Rlc3QvY29uZmlndXJhdGlv bi5wcm9wZXJ0
aWVzpY3BCsIwEETvgp/SYPAWyS3HQEFbvOSySRaaYqlstgX/3kREEAUPHmeY N69dkShFtDNE
pA4zi0iplGIEsimzNso5g6tz0Tdl4m+N3Akp9kI6d0m+9LWs8+2m/fIGDB4y nhMPpzDgBKI/
Wj1GH9SDVFXQ4XStmpLNE8jl+YM9BEJg1EwL/tTNC/9jfOHv0jtQSwMEFAAA AAgACXtZOKTx
WcZcBgAAYRkAAIEAAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29ubmVjdGl2 aXR5LnNxbS5s
b2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nvbm5lY3Rp dml0eS9zcW0v
bG9hZGVyL3Rlc3QvT3ZlcnJpZGVMb2FkZXJUZXN0LmphdmHNWdtu2zgQfVaA /ANhFKjculR3
X9Mu6sReNItcurGDok8FLVE2U5lURSqOd9F/3+FFN0t27SYt9iW2xZnh8PDM 8FBJSfiFzCkS
2RzTMGGppDgiiighEolDwTkNFbtnao3l1yVOBIlohhWV6uT46PiILVORKSTB gYXoLudM4Tgj
S7oS2Rc8lJJmChPz8SdJJD05yGWa5bQ+zR25J5gJfH49fghpqpjgJ+1BnuZq ojJKlhuD8muC
z9yKWp56cPL3xbbAuWIJvmBm2a3nHzKRQrqMynq2e0BaZQMhYpbQjun3CHPe inOQu/O5JByY
kB3kqjkRioziTFFIA4wSMb+e3YHB9+IsRUSTGYFnGnoZLuiSYBfhh3xHMKyf /ZDzxHx0u9Jl
DItcLgW32z1u8kCbWhoPY7WJnx04pTGA1DUyLSopePHi+Ai9QPqBRGCO1ALK 8p5mGYvohak7
RB8U5RK2GaWCcYWNh3UTaEm+UOOkTIgsBytDzGQ9QGuRowW5h0GBSHSXS2VM 05K5iHETCLY3
ZvM8I5pNuDbuRxmDbCTwPkOaL4jwyASJHPAoEaFx62P0SeQmnFyIPIlsbjLP 6AA8iGq6MUiW
hlCwikbIZ1wqSiIkYpRLxucwjYlEHwB1/Vtw2tdPguOjNJ8l0ETCBPoFum5g pXG0eEUSOVrV
Rv7VmHspLAlmLZpRzDhJEPQOPc1oOB2eDifjzx/Pp++vb6efJ2fvx5dD9Bb1 CqahFVOwPoUs
e9Dzy0/W6HnvBAXBs6vrq1dXF5NXvz07bLZtUz3BPJefasGLMJ1RqqaGdAKN HlcftLQ43Wni
FvER1mCXsJcpINthDfYlKO3AJ9uGy2A2hCk3z9WbLgog6qriZkZlnijNQcI3 izCiqSEVVCFT
z3XhcJrZYBpxis13YKf3TgfXG2Jpei9YZE3iPGmy1e9rRnqeaS1vbKJ/INub DETeDHoXhWQW
RNbX4QUBJMwq4FAkAEYulCt3WIwNU9tu7ediAw1835VHvxswPKfKWUi/r3/5 r/vm047DQ5Nh
mRnEhC6iCFSyfeC7yQYV/axLTRn4FdVdz9BrcHEay0AvqzCDCo9+F4nb8BSZ PQKZXwSLVj9t
VNqIPBKQPfhiOr2d34XQ9hlVecYRKeyhWEz9cNBy2sz3m4JgC736OKMx1Nvi sXg5Gk0bq3sq
LnnfDHzv7Em+WdOARAolrBaZWElUijhb02a0amFmmQ5Ge+gBhNACZmvXSnVj 0TnGyVqbWZuR
GQI6GMPxckajCE7Lv0anZ8iO9QZwWphvIxpzvNOwq2dvrrn+6/dnmymrlahA Tq2AlLXMDWWc
VCxBGLWKyO15a7RkhzVw4Bt9tYE9aIVsJFa86KA6xURAUiRJKs1QiFbBpTZq C+ZiDUC6phzW
BX0OkoTwkNoyd+On6ysgut91cHfQx3PxccSkS6YkwpNMXSmUA2Z3wLa4XGdr werapcupJ692
1YJT0H15i3Rj1IrM5nxDpcizkA6lNfB7AcjfwInroNTlQf1iEcDFIrCXzUDL 2cDo9UqN9rqb
W1OoQCqcrtBG6W1amTutX6Rf7ElXhWyL12WLAZlhkvjNuXbb+z2Q1loAQIWe NWS4PlSMfvN7
bZWLbTxcOPc3seko5F2KbOsyd/jsXO53/PzeHhfNaIaLOJr7ptnpDjc6rcK2 SLHZwp4ul9ub
i0M3qS0gdJBDN6tDE++zXx1u+27ZFtd9kdqxa2XkAzduW0bazvP2zOtxO1iJ 4302cVub7ToP
i3a7/dWQPedKXViewm/d2VyMdB5Ng4NAMrIEUyciyuEyJy0ldlTU97bVndc7 Xw6QZEXWUkuz
unArpKmOUCGlj3kj27cJT3MgVfauUFS2tph64I8tiBOAhC4ph3MS0wca5gqk 5dnNeDgdI3eB
bojHrkP3GwqJChfIr79XRNQJFb1yNuegJiPzuoeL1UCrkBmZgXyKcvuqBvR1 AglF60rLWAjM
BNuaOYBQPNxxytfpVxNcP4uBlUL5qSTs6A5PwcMlg0vG/4CDo5vrD7+Ugebu tB/5Suh38a94
kbFxt+t68TEo3lrpK6VLWicKak0hBpO8PoGPN4U5luwfEMrw7OXLYoksRr72 xkrcpkCHM01L
gPNrDrfF4kJpLu/MbIwR1v2mdb8I5rkrr7L/l/AMCO6PG4rdfznsmuHPf1BL AQIUCxQAAAAI
AJJFWTjVHJzSpQAAADMBAAA9AAAAAAAAAAEAIAAAAAAAAABvcmcuZWNsaXBz ZS5kYXRhdG9v
bHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC8uY2xhc3NwYXRoUEsB AhQLFAAAAAgA
kkVZOGoGuCX7AAAAxwIAADsAAAAAAAAAAQAgAAAAAAEAAG9yZy5lY2xpcHNl LmRhdGF0b29s
cy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0Ly5wcm9qZWN0UEsBAhQL CgAAAAAATntZ
OAAAAAAAAAAAAAAAADcAAAAAAAAAAAAQAAAAVAIAAG9yZy5lY2xpcHNlLmRh dGF0b29scy5j
b25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L2Jpbi9QSwECFAsUAAAACACS RVk40ltg+z8A
AABQAAAAQwAAAAAAAAABACAAAACpAgAAb3JnLmVjbGlwc2UuZGF0YXRvb2xz LmNvbm5lY3Rp
dml0eS5zcW0ubG9hZGVyLnRlc3QvYnVpbGQucHJvcGVydGllc1BLAQIUCwoA AAAAAEp7WTgA
AAAAAAAAAAAAAAA8AAAAAAAAAAAAEAAAAEkDAABvcmcuZWNsaXBzZS5kYXRh dG9vbHMuY29u
bmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9NRVRBLUlORi9QSwECFAsUAAAA CAA0WVk4GlQJ
Ra0AAACEAQAARwAAAAAAAAABACAAAACjAwAAb3JnLmVjbGlwc2UuZGF0YXRv b2xzLmNvbm5l
Y3Rpdml0eS5zcW0ubG9hZGVyLnRlc3QvTUVUQS1JTkYvTUFOSUZFU1QuTUZQ SwECFAsKAAAA
AABKe1k4AAAAAAAAAAAAAAAANwAAAAAAAAAAABAAAAC1BAAAb3JnLmVjbGlw c2UuZGF0YXRv
b2xzLmNvbm5lY3Rpdml0eS5zcW0ubG9hZGVyLnRlc3Qvc3JjL1BLAQIUCwoA AAAAAEp7WTgA
AAAAAAAAAAAAAAA7AAAAAAAAAAAAEAAAAAoFAABvcmcuZWNsaXBzZS5kYXRh dG9vbHMuY29u
bmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL1BLAQIUCwoAAAAA AEp7WTgAAAAA
AAAAAAAAAABDAAAAAAAAAAAAEAAAAGMFAABvcmcuZWNsaXBzZS5kYXRhdG9v bHMuY29ubmVj
dGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2UvUEsBAhQL CgAAAAAASntZ
OAAAAAAAAAAAAAAAAE0AAAAAAAAAAAAQAAAAxAUAAG9yZy5lY2xpcHNlLmRh dGF0b29scy5j
b25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L3NyYy9vcmcvZWNsaXBzZS9k YXRhdG9vbHMv
UEsBAhQLCgAAAAAASntZOAAAAAAAAAAAAAAAAFoAAAAAAAAAAAAQAAAALwYA AG9yZy5lY2xp
cHNlLmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L3Ny Yy9vcmcvZWNs
aXBzZS9kYXRhdG9vbHMvY29ubmVjdGl2aXR5L1BLAQIUCwoAAAAAAEp7WTgA AAAAAAAAAAAA
AABeAAAAAAAAAAAAEAAAAKcGAABvcmcuZWNsaXBzZS5kYXRhdG9vbHMuY29u bmVjdGl2aXR5
LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2UvZGF0YXRvb2xzL2Nv bm5lY3Rpdml0
eS9zcW0vUEsBAhQLCgAAAAAASntZOAAAAAAAAAAAAAAAAGUAAAAAAAAAAAAQ AAAAIwcAAG9y
Zy5lY2xpcHNlLmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50 ZXN0L3NyYy9v
cmcvZWNsaXBzZS9kYXRhdG9vbHMvY29ubmVjdGl2aXR5L3NxbS9sb2FkZXIv UEsBAhQLCgAA
AAAASntZOAAAAAAAAAAAAAAAAGoAAAAAAAAAAAAQAAAApgcAAG9yZy5lY2xp cHNlLmRhdGF0
b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50ZXN0L3NyYy9vcmcvZWNs aXBzZS9kYXRh
dG9vbHMvY29ubmVjdGl2aXR5L3NxbS9sb2FkZXIvdGVzdC9QSwECFAsUAAAA CABLclk4066F
MwkBAAARAwAAeQAAAAAAAAABACAAAAAuCAAAb3JnLmVjbGlwc2UuZGF0YXRv b2xzLmNvbm5l
Y3Rpdml0eS5zcW0ubG9hZGVyLnRlc3Qvc3JjL29yZy9lY2xpcHNlL2RhdGF0 b29scy9jb25u
ZWN0aXZpdHkvc3FtL2xvYWRlci90ZXN0L2Jhc2UucHJvcGVydGllc1BLAQIU CxQAAAAIABF5
WTjoBgaOcwMAAH8LAACAAAAAAAAAAAEAIAAAAM4JAABvcmcuZWNsaXBzZS5k YXRhdG9vbHMu
Y29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMvb3JnL2VjbGlwc2Uv ZGF0YXRvb2xz
L2Nvbm5lY3Rpdml0eS9zcW0vbG9hZGVyL3Rlc3QvQ2F0YWxvZ0xvYWRlclRl c3QuamF2YVBL
AQIUCxQAAAAIABJuWTiwKxmaKAEAAGUCAAB8AAAAAAAAAAEAIAAAAN8NAABv cmcuZWNsaXBz
ZS5kYXRhdG9vbHMuY29ubmVjdGl2aXR5LnNxbS5sb2FkZXIudGVzdC9zcmMv b3JnL2VjbGlw
c2UvZGF0YXRvb2xzL2Nvbm5lY3Rpdml0eS9zcW0vbG9hZGVyL3Rlc3QvQ29u ZmlndXJhdGlv
bi5qYXZhUEsBAhQLFAAAAAgASXdZOJkoA0WPAAAAMgEAAIIAAAAAAAAAAQAg AAAAoQ8AAG9y
Zy5lY2xpcHNlLmRhdGF0b29scy5jb25uZWN0aXZpdHkuc3FtLmxvYWRlci50 ZXN0L3NyYy9v
cmcvZWNsaXBzZS9kYXRhdG9vbHMvY29ubmVjdGl2aXR5L3NxbS9sb2FkZXIv dGVzdC9jb25m
aWd1cmF0aW9uLnByb3BlcnRpZXNQSwECFAsUAAAACAAJe1k4pPFZxlwGAABh GQAAgQAAAAAA
AAABACAAAADQEAAAb3JnLmVjbGlwc2UuZGF0YXRvb2xzLmNvbm5lY3Rpdml0 eS5zcW0ubG9h
ZGVyLnRlc3Qvc3JjL29yZy9lY2xpcHNlL2RhdGF0b29scy9jb25uZWN0aXZp dHkvc3FtL2xv
YWRlci90ZXN0L092ZXJyaWRlTG9hZGVyVGVzdC5qYXZhUEsFBgAAAAATABMA 4AkAAMsXAAAA
AA==
--------------030801080508090304060203--
Re: Trouble with overrideLoader [message #590077 is a reply to message #41970] Mon, 25 February 2008 15:35 Go to previous message
Brian Fitzpatrick is currently offline Brian FitzpatrickFriend
Messages: 500
Registered: July 2009
Senior Member
Thanks for the test code... Let me do some playing with this and get back to
you.
--Fitz

"Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
news:fpun02$u6m$1@build.eclipse.org...
> Hello Brian,
>
> thanks for your reply. I wasn't sure if the mailing list is alive so I
> reposted the message here.
>
> I've a JUnit test for the override loader problem (the source is
> attached to this mail). It basically uses two different databases and
> retrieves the schemas for both of them. Afterwards it refreshes one of
> the databases and shows that this instance lists an additional schema
> (which belongs to the other database).
>
> To get the test running you should adjust the properties in
> configuration.properties to fit your environment (location of the Derby
> 10.1 driver, ...). The class
> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
> contains the test and should therefore run as "JUnit Plug-in Test".
> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
> can have look at the setup code :).
>
> Regarding the column loaders. I was afraid you said something like that.
> Luckily I've already derived tables, views and procedures, so I can
> easily add the column loaders.
>
> Thank you,
>
> Enrico Schenk
>
> Software Engineer
> Ingres Germany GmbH - European Technology Center
>
> Brian Fitzpatrick wrote:
>> Hi Enrico...
>>
>> Sorry I didn't get back to your mailing list posting earlier, but glad
>> you
>> reposted here.
>>
>> That's definitely an odd behavior you found with (1). I know that there
>> has
>> been some discussion of having multiple levels of override loaders with
>> priorities and such to allow for a hierarchy, so that may clear up this
>> issue in Ganymede.
>>
>> Can you provide some example code perhaps using Derby or one of the other
>> profiles to reproduce this issue? I'd be happy to look at it. Obviously
>> it
>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>
>> As for (2), yeah, I wondered about that when I wrote that code in the
>> first
>> place. Because of the way those are structured, you'd have to actually
>> override the routine loader or the table loader and provide your own
>> column
>> loader below them to avoid that problem. At this point I don't have a
>> better solution other than implementing the whole catalog loader down the
>> line.
>>
>> As for contributing your Ingres code, we'd love to have that in the
>> Enablement project part of DTP. Please contact John Graham
>> (john.graham@sybase.com) and he can help point you in the right
>> direction.
>>
>> --Brian Fitzpatrick
>> Sybase, Inc.
>> Sr. Software Engineer
>> DataTools Connectivity Lead
>>
>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>> news:fpl453$t64$1@build.eclipse.org...
>>> Hello,
>>>
>>> I am currently developing a bundle of plug-ins to provide Ingres support
>>> for DTP.
>>>
>>> At the moment I have two questions regarding to the catalog loading.
>>>
>>> 1. JDBC loader
>>>
>>> To provide additional catalog information for DTP, I use the
>>> "overrideLoader" extension point. This way I did not have to implement
>>> the
>>> entire catalog structure. After all I'm a bit unsure if I use the API as
>>> it is meant to be used. After testing the implementation of a table
>>> loader
>>> (it just replaces the view and the table factory), I have seen an
>>> unexpected result. The following steps were done in the data source
>>> explorer.
>>>
>>> 1. Loading table A's columns
>>> 2. Loading table B's columns
>>> 3. Refreshing table A's columns
>>>
>>> To my surprise I have seen the columns of table B as columns of table A
>>> (the effect occurs only when using an override loader).
>>>
>>> After having a closer look at the source code, I found out that
>>>
>>> * There is always exactly one instance of a specific override loader
>>> * The loader's instance is shared between all requesting objects (e.g.
>>> tables)
>>> * A loader has a catalog object that depends on the requesting object
>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>> instance of Table)
>>>
>>> When a object uses its cached loader, the loader is sometimes
>>> initialized
>>> with the wrong catalog object (due to sharing). Are the loaders meant to
>>> be used in a stateless way? If so, can you provide an example?
>>>
>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>
>>> JDBCProcedure.createParameterLoader() and JDBCTable.createColumnLoader()
>>> uses both the EClass of Column to find possible override loaders.
>>> Because
>>> of casting the result to the according loader (in JDBCProcedure and
>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>> table
>>> columns or procedure columns.
>>>
>>> Thanks in advance,
>>>
>>> Enrico Schenk
>>>
>>> Software Engineer
>>> Ingres Germany GmbH - European Technology Center
>>>
>>> PS: It's planned to contribute the plug-ins (including the source code)
>>> to
>>> the eclipse foundation. Can you point me in the right direction for the
>>> required steps?
>>
>>
>
>
Re: Trouble with overrideLoader [message #590088 is a reply to message #42004] Tue, 26 February 2008 21:13 Go to previous message
Brian Fitzpatrick is currently offline Brian FitzpatrickFriend
Messages: 500
Registered: July 2009
Senior Member
Hey Enrico...

Figured it out. If you create a BZ entry for me documenting the issue, I can
get a fix in probably by tomorrow morning for 1.6 M6. The issue is that you
are absolutely correct. I'm creating one and only one instance of that
override loader and then reusing it everywhere. The fix is to create a new
instance of the class each time the loader is created, and then your test
works beautifully.

So please create a new BZ entry for me in Connectivity and I'll get this
bugger fixed. Thanks for your patience!

--Fitz

"Brian Fitzpatrick" <brianf@sybase.com> wrote in message
news:fpun77$vkv$1@build.eclipse.org...
> Thanks for the test code... Let me do some playing with this and get back
> to you.
> --Fitz
>
> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
> news:fpun02$u6m$1@build.eclipse.org...
>> Hello Brian,
>>
>> thanks for your reply. I wasn't sure if the mailing list is alive so I
>> reposted the message here.
>>
>> I've a JUnit test for the override loader problem (the source is
>> attached to this mail). It basically uses two different databases and
>> retrieves the schemas for both of them. Afterwards it refreshes one of
>> the databases and shows that this instance lists an additional schema
>> (which belongs to the other database).
>>
>> To get the test running you should adjust the properties in
>> configuration.properties to fit your environment (location of the Derby
>> 10.1 driver, ...). The class
>> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
>> contains the test and should therefore run as "JUnit Plug-in Test".
>> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
>> can have look at the setup code :).
>>
>> Regarding the column loaders. I was afraid you said something like that.
>> Luckily I've already derived tables, views and procedures, so I can
>> easily add the column loaders.
>>
>> Thank you,
>>
>> Enrico Schenk
>>
>> Software Engineer
>> Ingres Germany GmbH - European Technology Center
>>
>> Brian Fitzpatrick wrote:
>>> Hi Enrico...
>>>
>>> Sorry I didn't get back to your mailing list posting earlier, but glad
>>> you
>>> reposted here.
>>>
>>> That's definitely an odd behavior you found with (1). I know that there
>>> has
>>> been some discussion of having multiple levels of override loaders with
>>> priorities and such to allow for a hierarchy, so that may clear up this
>>> issue in Ganymede.
>>>
>>> Can you provide some example code perhaps using Derby or one of the
>>> other
>>> profiles to reproduce this issue? I'd be happy to look at it. Obviously
>>> it
>>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>>
>>> As for (2), yeah, I wondered about that when I wrote that code in the
>>> first
>>> place. Because of the way those are structured, you'd have to actually
>>> override the routine loader or the table loader and provide your own
>>> column
>>> loader below them to avoid that problem. At this point I don't have a
>>> better solution other than implementing the whole catalog loader down
>>> the
>>> line.
>>>
>>> As for contributing your Ingres code, we'd love to have that in the
>>> Enablement project part of DTP. Please contact John Graham
>>> (john.graham@sybase.com) and he can help point you in the right
>>> direction.
>>>
>>> --Brian Fitzpatrick
>>> Sybase, Inc.
>>> Sr. Software Engineer
>>> DataTools Connectivity Lead
>>>
>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>> news:fpl453$t64$1@build.eclipse.org...
>>>> Hello,
>>>>
>>>> I am currently developing a bundle of plug-ins to provide Ingres
>>>> support
>>>> for DTP.
>>>>
>>>> At the moment I have two questions regarding to the catalog loading.
>>>>
>>>> 1. JDBC loader
>>>>
>>>> To provide additional catalog information for DTP, I use the
>>>> "overrideLoader" extension point. This way I did not have to implement
>>>> the
>>>> entire catalog structure. After all I'm a bit unsure if I use the API
>>>> as
>>>> it is meant to be used. After testing the implementation of a table
>>>> loader
>>>> (it just replaces the view and the table factory), I have seen an
>>>> unexpected result. The following steps were done in the data source
>>>> explorer.
>>>>
>>>> 1. Loading table A's columns
>>>> 2. Loading table B's columns
>>>> 3. Refreshing table A's columns
>>>>
>>>> To my surprise I have seen the columns of table B as columns of table A
>>>> (the effect occurs only when using an override loader).
>>>>
>>>> After having a closer look at the source code, I found out that
>>>>
>>>> * There is always exactly one instance of a specific override loader
>>>> * The loader's instance is shared between all requesting objects (e.g.
>>>> tables)
>>>> * A loader has a catalog object that depends on the requesting object
>>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>>> instance of Table)
>>>>
>>>> When a object uses its cached loader, the loader is sometimes
>>>> initialized
>>>> with the wrong catalog object (due to sharing). Are the loaders meant
>>>> to
>>>> be used in a stateless way? If so, can you provide an example?
>>>>
>>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>>
>>>> JDBCProcedure.createParameterLoader() and
>>>> JDBCTable.createColumnLoader()
>>>> uses both the EClass of Column to find possible override loaders.
>>>> Because
>>>> of casting the result to the according loader (in JDBCProcedure and
>>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>>> table
>>>> columns or procedure columns.
>>>>
>>>> Thanks in advance,
>>>>
>>>> Enrico Schenk
>>>>
>>>> Software Engineer
>>>> Ingres Germany GmbH - European Technology Center
>>>>
>>>> PS: It's planned to contribute the plug-ins (including the source code)
>>>> to
>>>> the eclipse foundation. Can you point me in the right direction for the
>>>> required steps?
>>>
>>>
>>
>>
>
>
Re: Trouble with overrideLoader [message #590112 is a reply to message #42035] Tue, 26 February 2008 21:30 Go to previous message
Brian Fitzpatrick is currently offline Brian FitzpatrickFriend
Messages: 500
Registered: July 2009
Senior Member
Never mind... I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=220464

I'll get this checked in and it should appear in tomorrow's build.

--Fitz

"Brian Fitzpatrick" <brianf@sybase.com> wrote in message
news:fq1vdv$6ep$1@build.eclipse.org...
> Hey Enrico...
>
> Figured it out. If you create a BZ entry for me documenting the issue, I
> can get a fix in probably by tomorrow morning for 1.6 M6. The issue is
> that you are absolutely correct. I'm creating one and only one instance of
> that override loader and then reusing it everywhere. The fix is to create
> a new instance of the class each time the loader is created, and then your
> test works beautifully.
>
> So please create a new BZ entry for me in Connectivity and I'll get this
> bugger fixed. Thanks for your patience!
>
> --Fitz
>
> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
> news:fpun77$vkv$1@build.eclipse.org...
>> Thanks for the test code... Let me do some playing with this and get back
>> to you.
>> --Fitz
>>
>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>> news:fpun02$u6m$1@build.eclipse.org...
>>> Hello Brian,
>>>
>>> thanks for your reply. I wasn't sure if the mailing list is alive so I
>>> reposted the message here.
>>>
>>> I've a JUnit test for the override loader problem (the source is
>>> attached to this mail). It basically uses two different databases and
>>> retrieves the schemas for both of them. Afterwards it refreshes one of
>>> the databases and shows that this instance lists an additional schema
>>> (which belongs to the other database).
>>>
>>> To get the test running you should adjust the properties in
>>> configuration.properties to fit your environment (location of the Derby
>>> 10.1 driver, ...). The class
>>> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
>>> contains the test and should therefore run as "JUnit Plug-in Test".
>>> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
>>> can have look at the setup code :).
>>>
>>> Regarding the column loaders. I was afraid you said something like that.
>>> Luckily I've already derived tables, views and procedures, so I can
>>> easily add the column loaders.
>>>
>>> Thank you,
>>>
>>> Enrico Schenk
>>>
>>> Software Engineer
>>> Ingres Germany GmbH - European Technology Center
>>>
>>> Brian Fitzpatrick wrote:
>>>> Hi Enrico...
>>>>
>>>> Sorry I didn't get back to your mailing list posting earlier, but glad
>>>> you
>>>> reposted here.
>>>>
>>>> That's definitely an odd behavior you found with (1). I know that there
>>>> has
>>>> been some discussion of having multiple levels of override loaders with
>>>> priorities and such to allow for a hierarchy, so that may clear up this
>>>> issue in Ganymede.
>>>>
>>>> Can you provide some example code perhaps using Derby or one of the
>>>> other
>>>> profiles to reproduce this issue? I'd be happy to look at it. Obviously
>>>> it
>>>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>>>
>>>> As for (2), yeah, I wondered about that when I wrote that code in the
>>>> first
>>>> place. Because of the way those are structured, you'd have to actually
>>>> override the routine loader or the table loader and provide your own
>>>> column
>>>> loader below them to avoid that problem. At this point I don't have a
>>>> better solution other than implementing the whole catalog loader down
>>>> the
>>>> line.
>>>>
>>>> As for contributing your Ingres code, we'd love to have that in the
>>>> Enablement project part of DTP. Please contact John Graham
>>>> (john.graham@sybase.com) and he can help point you in the right
>>>> direction.
>>>>
>>>> --Brian Fitzpatrick
>>>> Sybase, Inc.
>>>> Sr. Software Engineer
>>>> DataTools Connectivity Lead
>>>>
>>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>>> news:fpl453$t64$1@build.eclipse.org...
>>>>> Hello,
>>>>>
>>>>> I am currently developing a bundle of plug-ins to provide Ingres
>>>>> support
>>>>> for DTP.
>>>>>
>>>>> At the moment I have two questions regarding to the catalog loading.
>>>>>
>>>>> 1. JDBC loader
>>>>>
>>>>> To provide additional catalog information for DTP, I use the
>>>>> "overrideLoader" extension point. This way I did not have to implement
>>>>> the
>>>>> entire catalog structure. After all I'm a bit unsure if I use the API
>>>>> as
>>>>> it is meant to be used. After testing the implementation of a table
>>>>> loader
>>>>> (it just replaces the view and the table factory), I have seen an
>>>>> unexpected result. The following steps were done in the data source
>>>>> explorer.
>>>>>
>>>>> 1. Loading table A's columns
>>>>> 2. Loading table B's columns
>>>>> 3. Refreshing table A's columns
>>>>>
>>>>> To my surprise I have seen the columns of table B as columns of table
>>>>> A
>>>>> (the effect occurs only when using an override loader).
>>>>>
>>>>> After having a closer look at the source code, I found out that
>>>>>
>>>>> * There is always exactly one instance of a specific override loader
>>>>> * The loader's instance is shared between all requesting objects (e.g.
>>>>> tables)
>>>>> * A loader has a catalog object that depends on the requesting object
>>>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>>>> instance of Table)
>>>>>
>>>>> When a object uses its cached loader, the loader is sometimes
>>>>> initialized
>>>>> with the wrong catalog object (due to sharing). Are the loaders meant
>>>>> to
>>>>> be used in a stateless way? If so, can you provide an example?
>>>>>
>>>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>>>
>>>>> JDBCProcedure.createParameterLoader() and
>>>>> JDBCTable.createColumnLoader()
>>>>> uses both the EClass of Column to find possible override loaders.
>>>>> Because
>>>>> of casting the result to the according loader (in JDBCProcedure and
>>>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>>>> table
>>>>> columns or procedure columns.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Enrico Schenk
>>>>>
>>>>> Software Engineer
>>>>> Ingres Germany GmbH - European Technology Center
>>>>>
>>>>> PS: It's planned to contribute the plug-ins (including the source
>>>>> code) to
>>>>> the eclipse foundation. Can you point me in the right direction for
>>>>> the
>>>>> required steps?
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Trouble with overrideLoader [message #590190 is a reply to message #42097] Wed, 27 February 2008 16:10 Go to previous message
Enrico Schenk is currently offline Enrico SchenkFriend
Messages: 23
Registered: July 2009
Junior Member
Thanks Brian, with the patch it works like a charm :)

Enrico

Brian Fitzpatrick wrote:
> Never mind... I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=220464
>
> I'll get this checked in and it should appear in tomorrow's build.
>
> --Fitz
>
> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
> news:fq1vdv$6ep$1@build.eclipse.org...
>> Hey Enrico...
>>
>> Figured it out. If you create a BZ entry for me documenting the issue, I
>> can get a fix in probably by tomorrow morning for 1.6 M6. The issue is
>> that you are absolutely correct. I'm creating one and only one instance of
>> that override loader and then reusing it everywhere. The fix is to create
>> a new instance of the class each time the loader is created, and then your
>> test works beautifully.
>>
>> So please create a new BZ entry for me in Connectivity and I'll get this
>> bugger fixed. Thanks for your patience!
>>
>> --Fitz
>>
>> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
>> news:fpun77$vkv$1@build.eclipse.org...
>>> Thanks for the test code... Let me do some playing with this and get back
>>> to you.
>>> --Fitz
>>>
>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>> news:fpun02$u6m$1@build.eclipse.org...
>>>> Hello Brian,
>>>>
>>>> thanks for your reply. I wasn't sure if the mailing list is alive so I
>>>> reposted the message here.
>>>>
>>>> I've a JUnit test for the override loader problem (the source is
>>>> attached to this mail). It basically uses two different databases and
>>>> retrieves the schemas for both of them. Afterwards it refreshes one of
>>>> the databases and shows that this instance lists an additional schema
>>>> (which belongs to the other database).
>>>>
>>>> To get the test running you should adjust the properties in
>>>> configuration.properties to fit your environment (location of the Derby
>>>> 10.1 driver, ...). The class
>>>> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
>>>> contains the test and should therefore run as "JUnit Plug-in Test".
>>>> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
>>>> can have look at the setup code :).
>>>>
>>>> Regarding the column loaders. I was afraid you said something like that.
>>>> Luckily I've already derived tables, views and procedures, so I can
>>>> easily add the column loaders.
>>>>
>>>> Thank you,
>>>>
>>>> Enrico Schenk
>>>>
>>>> Software Engineer
>>>> Ingres Germany GmbH - European Technology Center
>>>>
>>>> Brian Fitzpatrick wrote:
>>>>> Hi Enrico...
>>>>>
>>>>> Sorry I didn't get back to your mailing list posting earlier, but glad
>>>>> you
>>>>> reposted here.
>>>>>
>>>>> That's definitely an odd behavior you found with (1). I know that there
>>>>> has
>>>>> been some discussion of having multiple levels of override loaders with
>>>>> priorities and such to allow for a hierarchy, so that may clear up this
>>>>> issue in Ganymede.
>>>>>
>>>>> Can you provide some example code perhaps using Derby or one of the
>>>>> other
>>>>> profiles to reproduce this issue? I'd be happy to look at it. Obviously
>>>>> it
>>>>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>>>>
>>>>> As for (2), yeah, I wondered about that when I wrote that code in the
>>>>> first
>>>>> place. Because of the way those are structured, you'd have to actually
>>>>> override the routine loader or the table loader and provide your own
>>>>> column
>>>>> loader below them to avoid that problem. At this point I don't have a
>>>>> better solution other than implementing the whole catalog loader down
>>>>> the
>>>>> line.
>>>>>
>>>>> As for contributing your Ingres code, we'd love to have that in the
>>>>> Enablement project part of DTP. Please contact John Graham
>>>>> (john.graham@sybase.com) and he can help point you in the right
>>>>> direction.
>>>>>
>>>>> --Brian Fitzpatrick
>>>>> Sybase, Inc.
>>>>> Sr. Software Engineer
>>>>> DataTools Connectivity Lead
>>>>>
>>>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>>>> news:fpl453$t64$1@build.eclipse.org...
>>>>>> Hello,
>>>>>>
>>>>>> I am currently developing a bundle of plug-ins to provide Ingres
>>>>>> support
>>>>>> for DTP.
>>>>>>
>>>>>> At the moment I have two questions regarding to the catalog loading.
>>>>>>
>>>>>> 1. JDBC loader
>>>>>>
>>>>>> To provide additional catalog information for DTP, I use the
>>>>>> "overrideLoader" extension point. This way I did not have to implement
>>>>>> the
>>>>>> entire catalog structure. After all I'm a bit unsure if I use the API
>>>>>> as
>>>>>> it is meant to be used. After testing the implementation of a table
>>>>>> loader
>>>>>> (it just replaces the view and the table factory), I have seen an
>>>>>> unexpected result. The following steps were done in the data source
>>>>>> explorer.
>>>>>>
>>>>>> 1. Loading table A's columns
>>>>>> 2. Loading table B's columns
>>>>>> 3. Refreshing table A's columns
>>>>>>
>>>>>> To my surprise I have seen the columns of table B as columns of table
>>>>>> A
>>>>>> (the effect occurs only when using an override loader).
>>>>>>
>>>>>> After having a closer look at the source code, I found out that
>>>>>>
>>>>>> * There is always exactly one instance of a specific override loader
>>>>>> * The loader's instance is shared between all requesting objects (e.g.
>>>>>> tables)
>>>>>> * A loader has a catalog object that depends on the requesting object
>>>>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>>>>> instance of Table)
>>>>>>
>>>>>> When a object uses its cached loader, the loader is sometimes
>>>>>> initialized
>>>>>> with the wrong catalog object (due to sharing). Are the loaders meant
>>>>>> to
>>>>>> be used in a stateless way? If so, can you provide an example?
>>>>>>
>>>>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>>>>
>>>>>> JDBCProcedure.createParameterLoader() and
>>>>>> JDBCTable.createColumnLoader()
>>>>>> uses both the EClass of Column to find possible override loaders.
>>>>>> Because
>>>>>> of casting the result to the according loader (in JDBCProcedure and
>>>>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>>>>> table
>>>>>> columns or procedure columns.
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> Enrico Schenk
>>>>>>
>>>>>> Software Engineer
>>>>>> Ingres Germany GmbH - European Technology Center
>>>>>>
>>>>>> PS: It's planned to contribute the plug-ins (including the source
>>>>>> code) to
>>>>>> the eclipse foundation. Can you point me in the right direction for
>>>>>> the
>>>>>> required steps?
>>>>>
>>>>
>>>
>>
>
>
Re: Trouble with overrideLoader [message #590200 is a reply to message #42296] Wed, 27 February 2008 20:07 Go to previous message
Brian Fitzpatrick is currently offline Brian FitzpatrickFriend
Messages: 500
Registered: July 2009
Senior Member
Great news! Glad we could help! Let us know if you need anything else.
--Fitz

"Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
news:fq420r$k1i$1@build.eclipse.org...
> Thanks Brian, with the patch it works like a charm :)
>
> Enrico
>
> Brian Fitzpatrick wrote:
>> Never mind... I created
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=220464
>>
>> I'll get this checked in and it should appear in tomorrow's build.
>>
>> --Fitz
>>
>> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
>> news:fq1vdv$6ep$1@build.eclipse.org...
>>> Hey Enrico...
>>>
>>> Figured it out. If you create a BZ entry for me documenting the issue, I
>>> can get a fix in probably by tomorrow morning for 1.6 M6. The issue is
>>> that you are absolutely correct. I'm creating one and only one instance
>>> of that override loader and then reusing it everywhere. The fix is to
>>> create a new instance of the class each time the loader is created, and
>>> then your test works beautifully.
>>>
>>> So please create a new BZ entry for me in Connectivity and I'll get this
>>> bugger fixed. Thanks for your patience!
>>>
>>> --Fitz
>>>
>>> "Brian Fitzpatrick" <brianf@sybase.com> wrote in message
>>> news:fpun77$vkv$1@build.eclipse.org...
>>>> Thanks for the test code... Let me do some playing with this and get
>>>> back to you.
>>>> --Fitz
>>>>
>>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>>> news:fpun02$u6m$1@build.eclipse.org...
>>>>> Hello Brian,
>>>>>
>>>>> thanks for your reply. I wasn't sure if the mailing list is alive so I
>>>>> reposted the message here.
>>>>>
>>>>> I've a JUnit test for the override loader problem (the source is
>>>>> attached to this mail). It basically uses two different databases and
>>>>> retrieves the schemas for both of them. Afterwards it refreshes one of
>>>>> the databases and shows that this instance lists an additional schema
>>>>> (which belongs to the other database).
>>>>>
>>>>> To get the test running you should adjust the properties in
>>>>> configuration.properties to fit your environment (location of the
>>>>> Derby
>>>>> 10.1 driver, ...). The class
>>>>> org.eclipse.datatools.connectivity.sqm.loader.test.OverrideL oaderTest
>>>>> contains the test and should therefore run as "JUnit Plug-in Test".
>>>>> Btw. I'm not sure, if I used the DTP API in a proper way, so maybe you
>>>>> can have look at the setup code :).
>>>>>
>>>>> Regarding the column loaders. I was afraid you said something like
>>>>> that.
>>>>> Luckily I've already derived tables, views and procedures, so I can
>>>>> easily add the column loaders.
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Enrico Schenk
>>>>>
>>>>> Software Engineer
>>>>> Ingres Germany GmbH - European Technology Center
>>>>>
>>>>> Brian Fitzpatrick wrote:
>>>>>> Hi Enrico...
>>>>>>
>>>>>> Sorry I didn't get back to your mailing list posting earlier, but
>>>>>> glad you
>>>>>> reposted here.
>>>>>>
>>>>>> That's definitely an odd behavior you found with (1). I know that
>>>>>> there has
>>>>>> been some discussion of having multiple levels of override loaders
>>>>>> with
>>>>>> priorities and such to allow for a hierarchy, so that may clear up
>>>>>> this
>>>>>> issue in Ganymede.
>>>>>>
>>>>>> Can you provide some example code perhaps using Derby or one of the
>>>>>> other
>>>>>> profiles to reproduce this issue? I'd be happy to look at it.
>>>>>> Obviously it
>>>>>> warrants a BZ entry targeted for the DTP 1.6 release for Ganymede.
>>>>>>
>>>>>> As for (2), yeah, I wondered about that when I wrote that code in the
>>>>>> first
>>>>>> place. Because of the way those are structured, you'd have to
>>>>>> actually
>>>>>> override the routine loader or the table loader and provide your own
>>>>>> column
>>>>>> loader below them to avoid that problem. At this point I don't have
>>>>>> a
>>>>>> better solution other than implementing the whole catalog loader down
>>>>>> the
>>>>>> line.
>>>>>>
>>>>>> As for contributing your Ingres code, we'd love to have that in the
>>>>>> Enablement project part of DTP. Please contact John Graham
>>>>>> (john.graham@sybase.com) and he can help point you in the right
>>>>>> direction.
>>>>>>
>>>>>> --Brian Fitzpatrick
>>>>>> Sybase, Inc.
>>>>>> Sr. Software Engineer
>>>>>> DataTools Connectivity Lead
>>>>>>
>>>>>> "Enrico Schenk" <enrico.schenk@ingres.com> wrote in message
>>>>>> news:fpl453$t64$1@build.eclipse.org...
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am currently developing a bundle of plug-ins to provide Ingres
>>>>>>> support
>>>>>>> for DTP.
>>>>>>>
>>>>>>> At the moment I have two questions regarding to the catalog loading.
>>>>>>>
>>>>>>> 1. JDBC loader
>>>>>>>
>>>>>>> To provide additional catalog information for DTP, I use the
>>>>>>> "overrideLoader" extension point. This way I did not have to
>>>>>>> implement the
>>>>>>> entire catalog structure. After all I'm a bit unsure if I use the
>>>>>>> API as
>>>>>>> it is meant to be used. After testing the implementation of a table
>>>>>>> loader
>>>>>>> (it just replaces the view and the table factory), I have seen an
>>>>>>> unexpected result. The following steps were done in the data source
>>>>>>> explorer.
>>>>>>>
>>>>>>> 1. Loading table A's columns
>>>>>>> 2. Loading table B's columns
>>>>>>> 3. Refreshing table A's columns
>>>>>>>
>>>>>>> To my surprise I have seen the columns of table B as columns of
>>>>>>> table A
>>>>>>> (the effect occurs only when using an override loader).
>>>>>>>
>>>>>>> After having a closer look at the source code, I found out that
>>>>>>>
>>>>>>> * There is always exactly one instance of a specific override loader
>>>>>>> * The loader's instance is shared between all requesting objects
>>>>>>> (e.g.
>>>>>>> tables)
>>>>>>> * A loader has a catalog object that depends on the requesting
>>>>>>> object
>>>>>>> (e.g. the JDBCTableColumnLoader expects the catalog object to be an
>>>>>>> instance of Table)
>>>>>>>
>>>>>>> When a object uses its cached loader, the loader is sometimes
>>>>>>> initialized
>>>>>>> with the wrong catalog object (due to sharing). Are the loaders
>>>>>>> meant to
>>>>>>> be used in a stateless way? If so, can you provide an example?
>>>>>>>
>>>>>>> 2. ProcedureColumnLoader and TableColumnLoader
>>>>>>>
>>>>>>> JDBCProcedure.createParameterLoader() and
>>>>>>> JDBCTable.createColumnLoader()
>>>>>>> uses both the EClass of Column to find possible override loaders.
>>>>>>> Because
>>>>>>> of casting the result to the according loader (in JDBCProcedure and
>>>>>>> JDBCTable), I get some class cast exceptions when trying to retrieve
>>>>>>> table
>>>>>>> columns or procedure columns.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Enrico Schenk
>>>>>>>
>>>>>>> Software Engineer
>>>>>>> Ingres Germany GmbH - European Technology Center
>>>>>>>
>>>>>>> PS: It's planned to contribute the plug-ins (including the source
>>>>>>> code) to
>>>>>>> the eclipse foundation. Can you point me in the right direction for
>>>>>>> the
>>>>>>> required steps?
>>>>>>
>>>>>
>>>>
>>>
>>
Previous Topic:Installation problem pdt with eclipse 3.4.
Next Topic:"No connection" on a database that I am connected to
Goto Forum:
  


Current Time: Thu Mar 28 14:46:03 GMT 2024

Powered by FUDForum. Page generated in 0.04104 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top