Community
Participate
Working Groups
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
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?
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.
(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.
(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.
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?
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.
(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?
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.
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.
Created attachment 177270 [details] Temporary fix for maint
(In reply to comment #10) > Created an attachment (id=177270) [details] > Temporary fix for maint Thanks, will test and get back to you
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(); }
Created attachment 177362 [details] Updated patch Here is an updated patch that addresses the catalog issues.
Thanks Neil that last patch works.
Patch committed to 2.3.x maintenance branch.
