History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: IDEA-17765
Type: New Feature New Feature
Status: Open Open
Assignee: Gregory Shrago
Reporter: Taras Tielkes
Votes: 1
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
IDEA: Feedback

Allow SQL support to work with real datasource

Created: 15 Apr 08 16:27   Updated: 06 Jun 08 11:11
Component/s: SQL

Issue Links:
Relates
This issue relates to:
IDEADEV-27145 SQL: data source definition may have ... Normal Open
 

Build: 8,280
Severity: High


 Description  « Hide
At the moment the SQL language support resolves against the combined set of SQL DDL files found in the project (if I understand correctly).
A project may not always contain an up-to-date or complete set of DDL scripts.

It would be nice if I could use a real datasource instead.

Navigation and resolving could use a read-only/generated DDL script, similar to how resolving to binary Java code uses a decompiled stub.
Of course, such 'synthetic' DDL would probably only contain only generic SQL DDL CREATE TABLE etc statements, missing out vendor-specific extensions like custom index options, etc. But I think that would be fine.

Having such a feature would open the path to other interesting functionality: previewing table and column contents (for example: first 15 rows), executing queries, etc.



 All   Comments   Work Log   Change History      Sort Order:
Alexander Chernikov - 05 Jun 08 21:14
8437: if you have "select * from table1;" statement, and a data source with table1, then ctrl+b jumps to Database tool window.
But if you also have "create table table1 (...);" statement, then ctrl+b jumps to that statement.

There are at least two open questions here:
1) how to select correct data source (several data sources may contain same named table),
2) should the reference be resolved into existent "create table" statement after that.

Regarding point 1. It could be possible to tie particular .sql file to particular data source. It would be solution for point 1, and also user will not have to specify .sql dialect in project settings / file/directory options.

The GUI for this operation could be similar to existent GUI to define JSP and ant script contexts. (You can open some ant script, imported into another one, in the editor. Then click on Hector's head in status bar and specify, what super-script imports this one. This affects resolving of identifiers in imported script. Settings are stored in project file.) The same way, user could select a data source for .sql file.

@see IDEADEV-27145


Taras Tielkes - 06 Jun 08 11:10 - edited
Sascha, this is what I was thinking when I filed this issue:

There are two possible models to resolve SQL agains:
1) SQL DDL files
Pros:

  • more close to traditional IDEA resolving: target is a text file inside the project
  • refactoring operation have a clearly defined target

Cons:

  • user must have or create a complete DDL script to have this work.
  • no possibility to provide query and/or data preview abilities in IDE
  • after refactoring the user will have to update the real database to synchronize the changes done in IDEA

2) Real datasource
Pros:

  • Just connect and go - database provides all structure: table/view/column names
  • Additional features can be provided: preview table/column values, provide some query execution abilities

Cons:

  • Refactoring operations cannot be applied directly - instead IDEA could generate DDL containing ALTER TABLE/COLUMN statements

Any refactoring operation requires additional work in both modes - but that is simply the nature of database models: you don't (want to) operate against a live, mutable thing, so at some point the refactoring performed will have to be applied to the real database.

The main benefit of (2) is that IDEA could provide query execution/testing abilities, and data preview for tables/columns.

As for configuration, I imagined a SQL facet.

Anyway - this is all just brainstorming - feel free to provide comments and ideas.