RE: [stellation-res] SQL name length question

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxxxxxxxxx>]

On Sun, 2002-09-01 at 17:21, Jonathan Gossage wrote:
> > >For now, we're still generating the queries manually... So the column
> > >names can't vary by database.
> > >
> > >Also, we had a summer student, named Annie Ying working on Stellation.
> > >Annie had the very interesting observation that by using a database, we
> > >enable extenders to write code to do things like data mining directly
> > >against the database. It's a really interesting idea, which she's using
> > >to try some really neat stuff. The basic idea behind what she's up to is
> > >that there is some very interesting information in the development, but
> > >that the standard repository interface is not well suited to doing
> > >things like mining that information.
> > >
> > >I think that tools that bypass the standard repository interface can
> > >be very interesting and valuable. (I also think that they should be
> > >read-only with respect to the repository tables, but that's a different
> > >issue.) So I'd like to make sure that we keep things in a form where
> > >other tools can access the repository tables directly.
> > >
> > >This isn't an argument against adding an abstraction layer for SQL
> > >DML... But it is an argument for making sure that any such layer
> > >doesn't hinder the ability to access the database from outside of
> > >the normal repository code. (Annie's code uses an access point to get
> > >a database object, and then uses the database object to access the
> > >tables.)
> > >
> > >	-Mark
> > >
> 
> Are you going to make the assumption that other external tools will go
> through an access point? If so the existing code could easily handle the
> differences in column names by simply asking the access point for the name.
> Incidentally, not only researchers, but administrators may be interested in
> this ability which would allow the development of custom reporting to meet
> individual organization requirements.

Yes, I think we should require external tools to go through the access
point. That way, we can make sure that external tools are forced to
conform to Stellation rules - like the comment I made about only reading
repository intrinsic tables.

I did an experiment in the new schema for text artifacts, where instead
of writing queries with column names directly in the queries, it
references column names stored in static final string variables. I
consider the experiment a failure: the resulting SQL may be more robust
against name changes, but it's *very* hard to read. Much harder than
literal SQL.

On the basis of that, I really don't want to require an awkward
programmatic way of getting at column names. We shouldn't do it,
unless it's part of a carefully designed SQL abstraction mechanism
that's easy to use, and that makes SQL statements as easy to read
and understand as they are as literal strings.

> Are you looking at providing other access for languages besides Java? In
> this case you have another interesting set of land mines to negotiate. In my
> organization we have just completed a C/C++ interface to part of our Java
> based product and the exercise had its' moments.

We definitely hope to support more than just Java. 

C and C++ are, frankly, not likely contenders. In a previous lifetime,
I helped work on what became VisualAge C++ 4.0, and I know all too
well how utterly horrific C++ parsing and processing can be. To build
fine-grained support for C++ that included the ability to do queries,
and to get the query results *right* is an incredible amount of work.
It's not something that I'm anxious to do. If Stellation really catches
on, and the Eclipse folks were to decide that they wanted to use it for
fine-grained support, the CDT folks are welcome to do the C/C++ language
component for Stellation. Personally, I won't touch it with a 10 foot
pole.

The things that I see as likely contenders for language support beyond
Java: 
- Javascript. I dislike Javascript, but there are some websphere folks
 who do a lot with it, and I don't think it would be too hard to
 support.

- Python. Fun language, lots of users, and a reasonably easy one to tie
 into Stellation.

- OCaml. My personal favorite language. Given time, I would dearly like 
  to put together an OCaml plugin for Eclipse.

- XML Schema. There's a lot of work going on involving XML-based
 web services, and we've had a lot of people working on it tell us how
 useful Stellation-like capabilities would be for working on the
 schema for those services. It would be a really challenging thing to
 do, because it's so different. But it would be really useful,
 and a real test of the infrastructure of the system.

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email:
markcc@xxxxxxxxxxx