[dtp-sqldevtools-dev] SQL Dev Tools F2F Mtg Summary

[Sheila Sholars <sholars@xxxxxxxxxx>]

On 9/16/05, the SQL Dev Tools project met face to face at the IBM Silicon Valley Lab in San Jose, CA to get the project off to a good start. Here is a glimpse of what occurred. Thanks to Rupesh Kartha for assisting with the summary.

Data Tools Platform Project
SQL Development Tooling Meeting
IBM Silicon Valley Lab
09-16-05

Attendees: 
·	Actuate

o Linda Chan
o Gary Xue

·	IBM

o Der Ping Chou (on phone)
o Tom Christopher
o Christian Kadner
o Rupesh Kartha
o Brian Payton
o Sheila Sholars

·	Sybase

o John Graham (on phone)
o Hung Hsi

(See attached file: 100-0015_IMG.JPG)
In the photo...L to R: Tom, Hung, Sheila, Brian, Christian, Rupesh, Linda, Gary

Agenda:
n	10:00-10:30 (30) Introductions, Goals, Milestones, Dependencies
n	10:30-11:00 (30) SQL Query Model  (IBM)
n	11:00-11:30 (30) SQL Query Parser  (IBM)
n	11:30-12:15 (45) Connectivity (Sybase/Actuate)
n	12:15-1:15 (60) Lunch
n	1:15-2:15 (60) SQL Editor  (Sybase)
n	2:15-3:00 (45) Visual Query Builder (IBM/Actuate)
n	3:00-4:00 (60) Routines  (Sybase)
n	4:00-4:15 (15) Wrap-up
Not on the agenda was a discussion at the end where Linda gave us a better understanding of ODA.

The purpose of this meeting was to kick start the SQL Development Tooling effort.  With an aggressive schedule, we managed to fulfill our goals which were to:
n	Establish common vision for SQL Development Tools project
n	Better understand contributions and roles
n	Confirm content, dependencies, priorities and milestones
n	Architect components to allow for optional usage, where applicable
n	Gather input required to enhance our project plan

As each component representative gave an overview of the component, interactive discussion ensued regarding features, priorities, dependencies and timing.  We agreed to architect the tooling in such a way as to allow for easy inclusion or exclusion by consuming products.  One of the key results of the meeting was a complex, low-fidelity (i.e. using paper, pens and stickies) dependency chart, which we will endeavor to capture in a more suitable fashion for sharing.  

Overall, the session was seen as essential in order to establish a plan for bringing together contributions from various companies into one unified set of tools.  Some of the notes captured from each topic follows:

SQL Query Model (Brian)
·	SQL Model brought over form WTP project
·	SQL Query Model is an extension of the SQL Model
·	Models objects stored in db catalog (tables, triggers, views, data types, …)
·	Rational Rose used to model, but other methods available for modeling usable by EMF code gen utilities
·	Base model is vendor-neutral
·	On-demand loading allows you not to have to load entire database info
·	SQL Query Model

o SQL Query Model extends SQL Model (uses Statements hook)
o Models constructs for SQL queries
o Can also be used for query analysis

·	From Model to Code

o Run through EMF utilities which generates code
o All model elements end up in a package
o EMF generates an interface and an implementation class

·	Benefits of Using Models

o Can better understand what you’re dealing with
o Once you have a model, can do interesting things such as round-tripping (run through parser, generate model, redisplay into GUI)
o Can be used in conjunction w/ parser to enable smart editing

SQL Query Parser (Christian, Rupesh)
·	DML only at this point
·	Cycle: give SQL to parser, parser validates, generates model if valid, can traverse generated model, update model, generate source, …
·	Can work w/o connection, but if connected, tools can do semantic validation (e.g. verify table existence, data types, etc).  
·	Enables smart editing (smart highlighting for soft keywords, auto syntax completions, etc.)
·	Error diagnostic:  parser gives position in input text and error completion suggestions
·	Vendor neutral, but extensible.  Eg to support vendor-specific syntax: add rules to model extension, extend base parser, regenerate parser 
·	To support older SQL syntax (e.g. SQL-92):  Either use a separate parser or use parser rules to exclude features and exclude elements from UI.

How does model and parser fit in w/ other tooling?
·	Actuate:

o Use models w/ editor in BIRT.
o BIRT runtime: need ability to parse SQL. Manipulate report, add/remove columns, resort, change conditions (where clause).
o No DDL in BIRT
o Need to support Stored Procedures
o No vendor-specific support.
o ODA framework: push down data manipulation to data source. Eg additional filtering.

·	Sybase

o Essential for Visual Query Builder
o Editors: reverse engineering for query. Eg highlight query, launch Visual Query Builder.

Connectivity (Hung)
·	Rob at Sybase leading this effort
·	Refer to Rob’s Connectivity plan
·	Key SQL Dev Tools connectivity requirement:  Populate SQL Model… doesn’t matter how it’s populated.  Some connection types we’ll be able to use (i.e. ones which map to SQL Model) and other connection types our tooling won’t be able to utilize.
·	Create new conn profile, select driver, specify conn info (host db name, port, ...).  content provided by model loader
·	Data Source Explorer

o top level is categories
o under it are connection profile instances (simple interface, like Eclipse content provider, gets connection types, handles to connection objects, version info, tree content, …)

·	Q: vendor-specific drivers available?:  A: No vendor-specific extensions in DTP.  Vendor may provide basic pre-build as down-loadable binary w/ access to source.  But can’t put in cvs repository.  Then vendor can add a more optimized version of their features in their own product offerings.

SQL Editor (Hung)
·	Routines framework uses the SQL Editor
·	Framework APIs to remain internal for now
·	There is no  exemplary client for Routines
·	Design review of the SQL Editor framework to be done around in Oct.
·	Uses Results view and Execution plan view , which are separable components
·	Results view is needed by several components so will be a common component
·	Execution plan is retrieved as XML.
·	Results View , Scripts History and Output view have provide similar functionality, will need to consolidate
·	Combining SQL Editors

o SQL Editor has capability to pull routines information from SQL model, works based on raw SQL
o Need to replace the current parser with generic parser, but DDL support is needed
o Can use the existing SQL Editor framework to start creating the combined editor

·	Drag/drop server objects is not supported now, may be doable.

Visual Query Builder (Sheila/Gary)
·	General agreement on several points:

o Preferred name is “SQL Query Builder”
o Based on model/parser in DTP
o Model-view separation required
o Needs to be componentized for reuse (SQL Editor, _expression_ Builder, Conditions Builder, Graphical Joins, …)

§	Need to ensure SQL editor scope limited to DML in this context

o Actively design and code during 1.0, but delivery post 1.0

·	BIRT requirements:

o Round-tripping
o Componentization
o D&D of SQL objects

Routines Framework (Hung)
·	The Eclipse launch configuration is easily doable
·	Save As, Deploy and Run are proposed to be part of DTP APIs. Vendors will have to implement
·	No reference implementations at this point, a Derby based implementation needs to be investigated 
·	No additional annotations – user preferences (compile/build for debug etc )- are not planned  in the framework
·	Need to ensure that the framework is extensible , routines are the most varying among vendors

ODA (Linda) 
·	The ODA framework is intended to provide an abstraction for scalable data retrieval of heterogeneous data sources.  Thus, it serves a different purpose than other standard data-centric frameworks, such as JDBC and SDO, which all have significant focus on data updates among other things.
·	which all have significant focus on data updates among other things.
·	Data sources are defined using extension points
·	There are ODA Data types defined 
·	APIs are similar to JDBC, but implementations may be using non JDBC sources
·	Any type of queries (non-SQL as well) are possible 
·	How to integrate ODA:

o Adding to the right nodes of the data source explorer objects, to add ODA capabilities – there may be requirements from ODA on the explorer

·	Does SDO pull all the data to client side since it works in disconnected mode? 

TODOS:
·	Clean up notes and distribute (Rupesh/Sheila)						Target: early next week
·	Enhance SQL Dev Tools project plan (Sheila/Hung/Gary)				Target: meet next week

Will need to ensure no deliveries in last milestone.

·	Open call for Connectivity design/direction  (John/Rob, Sybase)			Target: next week (maybe next Tues 9/20)
·	Consider separation of the SQL Editor and Routines/Debugger (Hung) 			Target: will address in initial design in mid Oct.
·	Ensure that the Execution plan XML schema is vendor neutral  (Hung)			Target: will ensure the XML is published along with the design spec in Oct. for dev review
·	Understand feasibility of Derby based exemplary tooling for routines/debugger (Sheila)	Target: next week


Regards,
Sheila Sholars

Attachment: 100-0015_IMG.JPG
Description: JPEG image