After a week, we've had 7 responders. No, it's not a huge number, but it's honestly better than I was expecting. And we've had some interesting responses...The answers to the first question about where our users actually use DTP was shocking to me. I had no idea that this many folks actually used DTP for its standalone database functionality rather than as part of a larger suite.
For the second question, overwhelmingly nearly everybody who uses DTP seems to use it more as a developer than as a user.
Some of the responses as to where folks would like to see DTP get used were also interesting:
- As a replacement for SQuirreL SQL inside Eclipse.
- As more integrated with the IDE
- Or as a standalone RCP SQL Tool like PL/SQL Developer
angle in the beginning of DTP, but I hadn't heard that mentioned for a while. Sounds like the PL/SQL Developer is a similar request for functionality, but perhaps as a RCP application. We actually started a bit of this effort in the last release that's available in CVS (look in the Enablement project for the org.eclipse.datatools.enablement.rcp plug-in - it's rough, but it's a start).
And then we had some very thought provoking requests for new functionality...
- Provide documentation about what is supported for each database... e.g. "how do I see an SQL query explain for Sybase ASE or DB2 UDB"?. After hours of experimenting I *think* its not possible but can't tell for sure.
- Offer the ability to specify an order when executing a batch of sql files
- ETL functionality - data extract and load
- Easier handling - see PL/SQL Developer! More DB-Status functions
- Improve the SQL parser as a standalone library
I'm not quite sure what we'd do for #1 or #4, the rest are pretty self-explanatory. Though we'd love to have any/all of these entered as feature requests in Bugzilla, it's great feedback. We *LOVE* feedback.
Do *YOU* have more suggestions for us? Well, if you haven't already filled out the survey, go ahead and fill it out now (click here for the survey). If you've already filled out the survey, feel free to join the mailing list (dtp-dev@eclipse.org) or put a message on the forum/newsgroup and let us know what you're thinking.
And as always, we're looking for help - whether it's testing and reporting bugs, contributing patches, or becoming a committer!
Thanks to everyone who's filled out the survey so far and thanks in advance to anyone else who does the same!
4 comments:
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 (nevermind expecting extenders to adhere to any sort of pattern - maybe you could specify the behavior in your API...). See bug 249013.
Just documenting the 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 also causes us grief with DTP extenders because the API contract is not clear (intentionally?). For example, we have an extender that thinks returning tables and aliases from a call to Database.getTables() is appropriate, even though the "alias tables" then return an empty collection from a call to Table.getColumns(). See bug 269057.
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, an annotation might specify
table="Foo"
but, depending on the database server (e.g. Sybase or Oracle), that name resolves to the table named "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). 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.db.internal.vendor.FoldingStrategy.
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). It seems like all this "identifier" stuff belongs in DTP. I should be a able to query a DTP container for its element 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 a query 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.
Anyway, just some ideas. Is it reasonable to file bugs, or am I just dreaming? :-)
Brian Vosburgh
thanks for your sharing,Look here I appreciate this. keep up the good work
Thank you very much for figures. http://www.online-essay-writer.org/ I was looking for such information!
To help with statistics homework this website is perfect and it can go with every students experience. I hope this will have strong impact.
Post a Comment