All I want for Christmas 2008 - Full Featured Eclipse Database plugin

Full Featured Database Plugin for Eclipse.

Definition is vague, and of course dependent on whom you talk to. I, personally, am more of a developer than a DBA, so you could instead call what I'm asking for as a 'Developer Database Plugin' versus a 'DBA Database Plugin'.

So why not use SQLexplorer, DTP, Clay, or the several other Eclipse plugins that, yes, I have tested/used?

Because, they are missing:

*Good Source Control Support
*Stored Procedure Support
*Simplified View Support
*Easy multi database support

Good Source Control Support (specifically Subversion)

For me, I immediately think of us spoiled Eclipse programmers that can:

1) See quickly on the navigation tree what items are different than what is in SCM (3 POVs, only worried about what is deployed to the DB server you are pointing to, and what is in SCM. Active Desktop changes should be deployed to the DB server you are pointing to first, then team-shared to SCM if all goes well).

2) Compare/Diff easily/visually between what is in SCM versus what I'm looking at now. I understand the tricky part is there is 3 POVs -- SCM, active desktop, and what is deployed to the server you are pointing to. From my standpoint, you always pull from the 'deployed db server' environment, compare to SCM, then make changes and deploy back to the 'deployed db server'.

3) Everything in SCM. Everything. Entire schema -- tables, stored procedures, functions, indexes, triggers, etc -- everything. Database specific security will be a bit trickier from an 'abstract' database standpoint, so that's ok, but no excuse on anything else.

Stored Procedure Support

This is so blatantly obvious it scares the heck out of me how many plugins don't support this. If it can be read from JDBC, or, more precisely, can be read via 'EXEC ' that could be a simple project to abstract out regardless of underlying database, it should be available from a plugin.

some caveats though --
1) Whatever mechanism is used to retrieve the deployed stored procedures, the -content- should be the same as what is stored to the SCM for easy compare/diff.

2) Keep the editors simple first. This means don't worry about it being t-sql, pl-sql, java, pgsql, etc -- just use simple text editors first, then work on developing more robust editors depending on the native stored procedure language of the underlying database. Work on it later....get this working for now first.


Simplified View Support

I'm not even going to bullet/number this. How many people raise your hands when you had to use DTP to drill down from the Database->Catalog->Schema-> when you thought you had pre-defined those values already in the connection. I'm all for flexibility, but tools like IDE and IDE Plugins are supposed to be designed for you to work effectively, so give us the ability to just look at what we want to look at (even if we have to configure it first).

Easy multi database support

Yes, we all know you can support any database that has a JDBC driver (one case). Yes we know there are specific features (Execution Plans, etc) that require custom code/integration/libraries for specific databases (second use case). But could you make it a little easier to get setup?

1) http://mirrors.ibiblio.org/pub/mirrors/maven2/ --- If you don't want to include the JDBC driver in your distribution, directly point your app to here under the right group id (directory structure) and let the person through your UI just pick a version and automatically download it to the right location for your app. Manually downloading and adding to the /lib, or classpath, is so old-school.

2) see #1. Dont be old school.

3) I really do like seeing more advanced tools like Execution plans, but don't let that be your primary focus unless you are running out of bugs/features. 80% of developers working with databases need all this other 80% functionality first.


Data Modelling

-1) This is not my list above.
-2) I actually enjoy Data Modelling, but unfortunately when it comes to hitting the ground running, sometimes it gets in the way and you need as direct access to the actual database you are working with (the specific MS SQL, specific Oracle, specific MySQL, etc...) to get work done.
-3) Triggers/sprocs with modelling...yeah...
-4) There are some pretty decent Data Modelling out there, so no need to solve a problem that already has several implementations -- but my above list really haven't found a solution yet!



Update: I'm looking at liquibase.org for SCM support, but not sure if I can squeeze in enough time to give them a good test run.