Community
Participate
Working Groups
Build Identifier: WTP 3.2/Dali 2.3 An adopting product using it's own DTP vendor extension for SQL Server does not work with Dali since it's DTP extension doesn't support catalogs. This is related to the discussion in https://bugs.eclipse.org/bugs/show_bug.cgi?id=308947 and DTP allowing for optional support of catalogs in vendor extensions. Currently the SQLServer vendor class in Dali uses a SimpleCatalogStrategy that assumes catalogs will be supported. I have attached two patches for the WTP 3.2.x maintenance stream that fixes this (i.e. either change SQLServer to use UnknownCatalogStrategy, or change SimpleCatalogStrategy to handle the case of no catalogs). FauxCatalogStrategy already has the logic to handle the no-catalogs case. Just wondering, given that DTP allows for optional support of catalogs, would it be better to use UknownCatalogStrategy for all/most vendors since it appears to be best for handling all cases in a generic way? Reproducible: Always Steps to Reproduce: 1. Launch the new JPA project wizard 2. Use a connection for SQL Server using a product using a DTP vendor extension not supporting catalogs 3. The schemas will not display in the JPA facet config page or any other Dali tooling.
Created attachment 180679 [details] SimpleCatalogStrategy patch to make it handle the no-catalogs case
Created attachment 180680 [details] SQLServer patch to use UnknownCatalogStrategy
How is it that you support SQL Server without recognizing catalogs in your DTP Extension? I just assumed that SimpleCatalogStrategy databases were not a concern for your product.
(In reply to comment #3) > How is it that you support SQL Server without recognizing catalogs in your DTP > Extension? I just assumed that SimpleCatalogStrategy databases were not a > concern for your product. In speaking with the DTP folks who have also implemented these extensions, they say they've opted out of supporting catalogs in the extensions for various vendors since DTP allows for that. This particular extension is still compatible with SQL Server, and the rest of the extension tooling on top of DTP (for models, for db connectivity, etc) conforms to this (i.e. getting of all schemas and other information directly from the database object, etc).
Hi Neil, do you either of the patches (or perhaps another solution) can be implemented for the 2.3.x release to fix this issue of supporting DTP extensions that opt not to directly model catalogs?
Yes. I think the first patch is probably the better of the two, since that change will ensure other databases that use SimpleCatalogStrategy (namely Sybase) will also work correctly in these cases. I would also like to keep SimpleCatalogStrategy around for the future. The fix for bug 323437 may obviate the need for these changes in the next major release.
(In reply to comment #6) > Yes. I think the first patch is probably the better of the two, since that > change will ensure other databases that use SimpleCatalogStrategy (namely > Sybase) will also work correctly in these cases. I would also like to keep > SimpleCatalogStrategy around for the future. > > The fix for bug 323437 may obviate the need for these changes in the next major > release. Ok great thanks Neil. We'd like to get the fix as soon as possible on the WTP 3.2.2 patch builds. If you're ok with the SimpleCatalogStrategy patch for 3.2.2 and 3.2.3, I can work with Carl to get a 3.2.2 patch build going with the fix
(In reply to comment #7) > Ok great thanks Neil. We'd like to get the fix as soon as possible on the WTP > 3.2.2 patch builds. If you're ok with the SimpleCatalogStrategy patch for 3.2.2 > and 3.2.3, I can work with Carl to get a 3.2.2 patch build going with the fix OK...I will commit the change in our maintenance branch and post the tag so you can pick it up in your patch build.
(In reply to comment #8) > (In reply to comment #7) > > Ok great thanks Neil. We'd like to get the fix as soon as possible on the WTP > > 3.2.2 patch builds. If you're ok with the SimpleCatalogStrategy patch for 3.2.2 > > and 3.2.3, I can work with Carl to get a 3.2.2 patch build going with the fix > > OK...I will commit the change in our maintenance branch and post the tag so you > can pick it up in your patch build. Sounds good ... don't forget to increment the service field in manifest.mf, to 1.2.202.qualifier, if I'm seeing things right. (And then, remember to increment it again, if additional fixes made in R2_3_maintenance branch.). Thanks,
Thanks for the reminders. Tag is v201010192330 and released into 2.3.x maintenance.
Also fixed in head.
