Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321401

Summary: DTP extensions can lead to incorrect database specific behavior when vendor name doesn't match known DTP vendor
Product: [WebTools] Dali JPA Tools Reporter: Leonard Theivendra <theivend>
Component: GeneralAssignee: Neil Hauge <neil.hauge>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: danny.ju, neil.hauge
Version: 2.3   
Target Milestone: 2.3.2   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Temporary fix for maint
none
Updated patch none

Description Leonard Theivendra CLA 2010-07-30 16:19:23 EDT
Build Identifier: WTP 3.2.1

For Sybase
databases which have case sensitivity turned on by default, we are finding that
entities generated from the tables have attribute names that are lowercased and
therefore do not match with the uppercase columns, leading to problems at run
time when queries are run, etc.  Specifying a @Column(name="XYZ") mapping on
the field will solve this problem.  I didn't see any specific options in the
entity generator for this (it does have an option to generate extra annotations
but that doesn't seem to put in the column name info). Either we need to give the user the option to inject the @Column mappings or maintain the case in the generated attribute names.

Reproducible: Always
Comment 1 Leonard Theivendra CLA 2010-08-11 13:30:26 EDT
Hi, just want to bring this to the attention of the Dali team again. We would like to see a fix in WTP 3.2.2 if possible since it's a major problem for an adopting product. Can you let us know if this is possible?
Comment 2 Neil Hauge CLA 2010-08-11 14:09:31 EDT
This should be working, although I have not been able to verify that it is working yet on our side.  If you could take a look at this in debug perhaps we could get to the bottom of why this isn't working for you.  If you put a breakpoint in ORMGenColumn.getName() you can see how the names are converted based on the particular platform that is being used.
Comment 3 Leonard Theivendra CLA 2010-08-16 15:03:38 EDT
(In reply to comment #2)
> This should be working, although I have not been able to verify that it is
> working yet on our side.  If you could take a look at this in debug perhaps we
> could get to the bottom of why this isn't working for you.  If you put a
> breakpoint in ORMGenColumn.getName() you can see how the names are converted
> based on the particular platform that is being used.

Ok thanks Neil will try to do some more debugging.  The DTP adapters on our end could also be suspect.
Comment 4 Leonard Theivendra CLA 2010-08-18 13:54:05 EDT
(In reply to comment #2)
> This should be working, although I have not been able to verify that it is
> working yet on our side.  If you could take a look at this in debug perhaps we
> could get to the bottom of why this isn't working for you.  If you put a
> breakpoint in ORMGenColumn.getName() you can see how the names are converted
> based on the particular platform that is being used.

Hi Neil, it looks like the base cause for this issue is due to Dali registering a DTP adopter database connection for Sybase as "UnrecognizedVendor" in org.eclipse.jpt.db.internal.vendor.VendorRepository.getVendor().  The adopter vendor name is "Sybase", but Dali only recognizes the DTP Sybase vendor names of "Sybase_ASA" and "Sybase_ASE".  This then results in the wrong case handling folding strategy being used, and that's the why the @Column(name="XYZ") annotations are not getting generated.

I suppose this is a general problem given that DTP doesn't provide standard constants to identify the various db vendor families.  So either Dali could provide an extension point for adopters to register their own DTP adopted vendors/handling, or perhaps make the string comparisons in org.eclipse.jpt.db.internal.vendor.VendorRepository.getVendor() a bit more general such as using substring comparisons/etc? The simplest fix would be add a third org.eclipse.jpt.db.internal.vendor.Sybase() instance in VendorRepository with a string value of "Sybase"

Let me know what you think.
Comment 5 Neil Hauge CLA 2010-08-19 16:56:19 EDT
We should probably evaluate the extent of divergence from DTP "standard" names to determine the size of the issue here.  "Sybase" is one case where the wrong Dali vendor is used, but we should probably look for other mismatches.  This may help determine the most appropriate solution.  Can you look into this?
Comment 6 Leonard Theivendra CLA 2010-08-20 11:18:27 EDT
In looking over the DTP extended db vendor implmentations in our product families for DB2 LUW, DB2 iSeries, Informix, SQL Server, and Sybase, etc, only the Sybase one seems to be using a name different from those in DTP.  I'm not sure about other adopters, but I suppose there's a chance someone could provide their own DTP extended vendor definition/implementation for an existing DTP db vendor family using a different name.
Comment 7 Neil Hauge CLA 2010-08-20 17:21:26 EDT
(In reply to comment #6)
> I'm not
> sure about other adopters, but I suppose there's a chance someone could provide
> their own DTP extended vendor definition/implementation for an existing DTP db
> vendor family using a different name.

That is possible, although to date we haven't had any requests for this type of support.  On one hand, a db platform extension mechanism seems most appropriate for this type of situation, but on the other, it seems like a overkill for 1 known case.  I don't suppose that bringing this vendor name into alignment with DTP is a possible solution?  I suppose DTP doesn't have a generic Sybase platform in this case, but one for ASE and ASA (I assume because there are some notable difference between the two).  Is the vendor extension meant to support either of these database platforms?
Comment 8 Leonard Theivendra CLA 2010-08-21 11:15:59 EDT
Fair enough, perhaps a DTP wrapper extension point mechanism is overkill for now. I am in discussion with this particular Sybase DTP extension's owners about renaming it to match the DTP names, but there's a lot of adopter code already in place to use this name, and there's also the issue of migrating customers' DTP artifacts from previous versions of products that used this name.  This particular Sybase vendor extension is meant to support both ASA and ASE.

Would it possible to add a third org.eclipse.jpt.db.internal.vendor.Sybase() instance in VendorRepository with a string value of "Sybase"? 
i.e. something like this.addVendorTo(new Sybase("Sybase"), list); in org.eclipse.jpt.db.internal.vendor.VendorRepository.addVendorsTo(ArrayList<Vendor> list)

This would be the simplest short term fix until an extension point mechanism is offered.
Comment 9 Neil Hauge CLA 2010-08-23 17:14:20 EDT
Title changed as this is not really a bug in Dali.

I'm attaching a patch for the maintenance stream only that will address this issue on a temporary basis.  Bug 323437 addresses the long term need in this area with more appropriate alternatives.
Comment 10 Neil Hauge CLA 2010-08-23 17:15:17 EDT
Created attachment 177270 [details]
Temporary fix for maint
Comment 11 Leonard Theivendra CLA 2010-08-24 12:22:57 EDT
(In reply to comment #10)
> Created an attachment (id=177270) [details]
> Temporary fix for maint

Thanks, will test and get back to you
Comment 12 Leonard Theivendra CLA 2010-08-24 13:33:35 EDT
Hi Neil, in testing the fix, I ran into another issue (the old catalog/schema loading problem with DTP extensions), so I also needed to add this change to org.eclipse.jpt.db.internal.vendor.Sybase.getCatalogStrategy() to finally get everything to work:

CatalogStrategy getCatalogStrategy() {
     if ( getDTPVendorName().equals(DTP_VENDOR_EXTENSION.getDTPVendorName()) )
          return FauxCatalogStrategy.instance(); // or UnknownCatalogStrategy
     else
          return SimpleCatalogStrategy.instance();
}
Comment 13 Neil Hauge CLA 2010-08-24 15:46:20 EDT
Created attachment 177362 [details]
Updated patch

Here is an updated patch that addresses the catalog issues.
Comment 14 Leonard Theivendra CLA 2010-08-24 16:00:44 EDT
Thanks Neil that last patch works.
Comment 15 Neil Hauge CLA 2010-08-24 16:18:45 EDT
Patch committed to 2.3.x maintenance branch.