| Various issues [message #662520] |
Wed, 30 March 2011 22:04  |
 Brian Vosburgh
Messages: 137
Registered: July 2009 |
Senior Member |
|
|
I commented on Brian Fitzpatrick's blog a few months ago [1] and wanted to repeat that comment here in a more public forum, in hopes of more feedback.
The question Fitz posed in his blog was "Do *YOU* have more suggestions for us?".
From Dali's standpoint, there are lots of things you could do for us. :-)
First would be to make the whole database/catalog/schema thing more consistent across the DTP-delivered drivers (never mind expecting extenders to adhere to any sort of pattern - maybe you could specify the behavior in your API...). See bug 249013. [2]
Just documenting the DTP API would be helpful. There's way too much:
"If the meaning of the 'Foo' attribute isn't clear, there really should be more of a description here..."
:-)
This lack of documentation also causes us grief with DTP extenders because the API contract is not clear. (Maybe this is intentional?). For example, we have an extender that thinks returning tables and aliases from a call to is appropriate, even though the "alias tables" then return an empty collection from a call to . See bug 269057. [3]
Dali has entire framework of code attempting to handle the folding of identifiers; so users can specify strings in their Java annotations or XML descriptors that resolve to the appropriate database object. For example, a Java annotation might specify
but, depending on the database server (e.g. Sybase or Oracle), that name resolves to the table named "Foo" or "FOO" or "foo". It's not easy to look up those names across different databases (and we're ignoring whether the currently executing database has been configured to do other than its default behavior). I'm guessing it would be helpful for any other tool that wants to use DTP in a predictable fashion for any sort of validation that DTP handle this folding. You can see the Dali code in implementations of org.eclipse.jpt.jpa.db.internal.driver.DTPDriverAdapter.
It would also be nice if DTP would handle delimited identifiers; again, in a vendor-specific fashion (e.g. most vendors accept double quotes, SQL Server accepts brackets, MySQL accepts backticks). It seems like all this "identifier" stuff belongs in DTP. I should be a able to query a DTP container for one of its elements in one of three ways:
1. with the case-sensitive "name", which should match exactly (what happens today)
2. with an appropriately case-sensitive "identifier" that is folded appropriately to a "name" before the lookup takes place
3. with a "delimited identifier" whose delimiters are stripped off before the lookup takes place.
Also, it would be nice to be able to get the appropriately-delimited name of a database object; i.e. the name is returned unchanged if it can be used as such in an SQL statement without delimiters, but it is returned delimited if delimiters are required (e.g. the name is mixed case on a "folding" database or the name includes special characters - again, those special characters are database-specific...). This would allow a user to select a database object from a list and a tool insert the appropriate code into a Java annotation or XML descriptor or some such, only delimiting the identifier if absolutely necessary.
Anyway, just some ideas. Is it reasonable to file bugs, or am I just dreaming? :-)
[1] http://fitzdtp.blogspot.com/2010/10/early-survey-results.htm l
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=249013
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=269057
|
|
|
|
Powered by
FUDForum. Page generated in 0.02873 seconds
] 
Search
Help
Register
Login
Home
